継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

【脳筋Tech】ダイエットの進捗を楽しくするための仕組みを作ってみた💪!

タダです.

みなさん,元気に脳筋してますか? 僕はというとコロナウイルスの影響で思うような脳筋生活を送れていなくて悶々としておりましたが,契約しているエニタイムが営業を6/1から開始すると聞いて圧倒的大歓喜でございます.そうはいってもルールがあるため守りつつ気をつけて身体をシバイていきたいそんな想いです.

www.anytimefitness.co.jp

さて,緊急事態宣言の中思うようなトレーニングができていない人が多く,太っちまったよ...と嘆くそんな皆さんに捧ぐダイエット支援のための仕組みを作りました.ダイエットが楽しいのって体への変化や数値の変化だと思います.そんな楽しみを Forecast の予測する力を使って実現を考えてみたので,この記事で作ったものの簡単な紹介と今後どうカイゼンしていきたいかを整理しておきます.

作った仕組み

作ったのは前回 Forecast で体重推移を予測したモデルを使ってユーザーが1日ごとに体重を記録したらそのデータを AWS にアップロードして定期的に Forecast の予測を行うワークフローです.

sadayoshi-tada.hatenablog.com

フローは次のように回ります.

①ユーザーがアプリケーションで体重をスプレッドシートに記録する

スプレッドシートのデータが S3 に CSV でエクスポートされる

③月に1度 CloudWatch Events をトリガーに Lambda が起動

④Lambda から Forecast のモデルを呼び出して体重予測

⑤Forecast の予測結果を S3 バケットに出力

仕組みの概要図

各プロセスの概要

それでは,各プロセスごとにどんな実装をしているかを簡単に紹介します.

①ユーザーがアプリケーションで体重をスプレッドシートに記録する

スプレッドシートに体重を記録するため,アプリケーションは Glide を使って作りました.Glide はスプレッドシートを使った PWA アプリケーションを開発できます.そんな Glide で簡単な体重を記録するための画面を作りました.これでユーザーは1日ごとの体重を記録できます.

f:id:sadayoshi_tada:20200530130144p:plain f:id:sadayoshi_tada:20200530130218p:plain

スプレッドシート側にこんな感じで記録されます. f:id:sadayoshi_tada:20200530130640p:plain

関連リンク

公式サイト www.glideapps.com

関連記事 sadayoshi-tada.hatenablog.com

スプレッドシートのデータが S3 に CSV でエクスポートされる

スプレッドシートに記録したデータを Forecast で扱える CSV ファイルでエクスポートします.エクスポート処理部分は Google App Script と Amazon S3 API Binding for Google Apps Scrip というライブラリを使って,指定のバケットにファイル名を指定して S3 アップロードします.これで S3 にデータを貯めるフローができました.

f:id:sadayoshi_tada:20200530133641p:plain

関連リンク

使ったライブラリ engetc.com

③月に1度 CloudWatch Events をトリガーに Lambda が起動

一ヶ月間貯め続けた体重データを予測分析にかけたいので月に1度の結果を予測する処理を回す Lambda を発火します.そのための CloudWatch Events を設定しました.日毎に予測処理を回してもいいかなと思ったもののこれは個人的な経験則ですが,目材したい体重にもよるものの3ヶ月ほどは継続してダイエット生活しないと体への変化って出て来にくいので継続して体重を記録して長ーくゆっくり取り組んでいけるものにしたいと思って月1で予測する処理を回すようにしました.月の始めに前月の進捗からどんな体重推移になっていくかを参考データとして見れたら計画もたてなおしたりもしやすいかなと思ってます.

f:id:sadayoshi_tada:20200530134302p:plain

関連リンク

CloudWatch ドキュメント docs.aws.amazon.com

④Lambda から Forecast のモデルを呼び出して体重予測

CloudWatch Events から Lambda が発火して Forecast の既に構築済みのモデルを呼び出して予測を行います.先のブログで作ったモデルを流用して分析を回せるコードを書いて結果を S3バケットに出力するようにしました.

⑤Forecast の予測結果を S3 バケットに出力

S3 バケットには後々更に分析を回せるよう Athena で扱える JSON ファイルで出力しています.次のデータが出力されたファイルの中身の一例です.

{
    "Forecast": {
        "Predictions": {
            "p10": [
                {
                    "Timestamp": "2019-09-01T00:00:00",
                    "Value": 64.94144439697266
                }
            ],
            "p50": [
                {
                    "Timestamp": "2019-09-01T00:00:00",
                    "Value": 65.59163665771484
                }
            ],
            "p90": [
                {
                    "Timestamp": "2019-09-01T00:00:00",
                    "Value": 66.24183654785156
                }
            ]
        }
    },
~~~中略~~~
}

今後カイゼンしたいこと

ユーザーが体重を記録して S3 バケットにアップロードし,予測処理を定期的に回すフローができたのですが,今後カイゼンしたいと思っていることを整理しておきます.

Glide を選択したが他のユーザーにも使ってもらえるようにする

現状,自分しか使ってないからいいのですが,他の人にも使ってもらえるようにするためには認証だったり,ユーザー個別のスプレッドシートを用意して記録と S3 へのエクスポートできるようにする処理ができないとなと思っています.

Forecast の予測モデルを最適化

Forecast の予測モデルには AutoML を使っています.使い始めて間もないので予測モデルの最適化もしていいモデルで予測処理を回したいです.

予測結果のデータから Athena などで更に分析

予測の結果を利用者の手元で可視化したりできてないので,どうにかしたいと思っています.先に触れてますがゆくゆく Athena にデータを食わせてデータを抽出したりなどできたらと考えてます.

まとめ

ユーザーの体重を予測するダイエット支援のアプリケーションで作った概要と今後やりたいカイゼンをまとめました.まだまだ粗いので継続的に改修していけたらと思いますが,自分が構想したものが手元で動いているとほんと嬉しいですね! もっと質を高めて興味ある方に使ってもらえるようなものにしていきたいので,その時はよければチェックしてくだサイドチェスト!(お決まり)💪

AWS で監視設計を学ぶなら『AWSを通じて学ぶ、監視設計』から読もう!

タダです.

業務で設計・構築フェーズから入ったプロジェクトの AWS 環境における運用保守に関わっているのですが,監視はどんな設定にするかが EC2 なら〇〇する,マネージドサービスなら〇〇するって決まっています.どう監視設計を進めていけばいいかを学びたいと思って技術書典応援祭で「AWSを通じて学ぶ、監視設計」を購入しました.読了後,本書の概要と合わせて自分が学べると感じたことを紹介します.

技術書典応援祭のページ techbookfest.org

Booth booth.pm

概要

本書の章立ては次の通りです.本編として81Pの内容です.

  • 第1章 監視の設計
  • 第2章 SLI/SLO
  • 第3章 AWSにおける監視設計
  • 第4章 監視対象の多様化
  • 第5章 ダッシュボード
  • 第6章 AWS上のサーバーレスアプリケーションの監視(ケーススタディ)

各パートの概要や本に記載がないことの説明は id:tenbo07 さんの記事にも記載があるので気になった方は一読するのがオススメです.

id:tenbo07 さんの記事 tenbo07.hatenablog.com

本書で学んだことおよび読了後の所感

自分は監視設計に関わったことがないので なぜ監視が必要か?監視を行うために必要な処理は何か? から入っていく1章があったおかげで後続の章の内容も頭に入りやすかったです.また,収集した情報からどんなアラートを設定するかで,心配だからといって闇雲に設定せず本当に必要なアラートを選別する大事さを学びました.あとは可視化ですね.監視の情報をわかりやすく表現して運用していくためにシステム同様継続的な見直しと改善の必要性を学ぶことができました.

個人的に特に嬉しかったのが,SLI/SLO の決め方をケーススタディを使って勉強できたことです.SRE の文脈で SLI/SLO が出てくるものの,どうしてやるのか?どうやって設定するのか?を理解できてなかったのですが,観点と計算式にも触れられていて参考になりました.SLI/SLO の話は NewRelic さんのブログや登壇資料で発信されているので合わせて参照するといいと思いました.

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12

モダンなシステムにSLI/SLOを設定するときのベストプラクティス blog.newrelic.co.jp

まとめ

AWSを通じて学ぶ、監視設計」で学べること,所感を整理しました.本書は1章から5章にかけてなぜ監視をするのか,監視でどんな情報を収集して表現・可視化するのか監視設計知識をインプットして,6章で監視設計の実践をしていくような内容になっているので,全般を通して監視設計と実装のノウハウを学べる内容だと感じました.100P以内の内容であるため,AWS の監視設計に関わる機会がない人がどんな観点で設計と実装していくのかをスピーディに抑えたい人にオススメです.本書を読んでから「入門 監視」といった書籍を読み進めていくとより理解を深められると思うので,僕も読んでいきます!

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

【データ収集】AppFlow を使って Google Analytics のブログのデータを S3 にアップロードする

xタダです.

先日,Amazon AppFlow がリリースされました.このサービスは,SaaSAWS へのデータフローをコーディングなしに自動化できます.AppFlow を使って S3 へデータをアップロードしてしまえば Athena や QuickSight で分析に使うことができます。この記事では,AppFlow の概要とこのブログの PV を解析と可視化するために Google Analytics を連携していきます.

Amazon AppFlow を使用すると、AWS のサービスと、Salesforce、Zendesk、ServiceNow などの SaaS アプリケーション間のデータフローを自動化できます。SaaS アプリケーション管理者、ビジネスアナリスト、および BI スペシャリストは、IT が統合プロジェクトを完了するのに数か月待つことなく、必要な統合のほとんどをすばやく実装できます。

aws.amazon.com

Google Analytics との連携

このブログのデータは Google Analytics に情報を収集しているのですが,AppFlow の連携先に Google Analytics をサポートしているため連携してみます.

事前準備

GCP 側で次のことを行います.

  • Analytics API を有効化
  • OAuth クライアント ID の認証情報を作る
    • ドキュメントでは内部向けを選択するようになっていますが,GSuite ユーザーじゃないと選択できないため外部向けを選択しています
  • OAuth 同意画面で ../auth/analytics.readonly と承認済みドメインとして amazon.com を追加する

docs.aws.amazon.com

発行されたクライアントID とクライアントシークレットを控えておきます.

f:id:sadayoshi_tada:20200522005207p:plain

AppFlow での設定

AppFlow のサービス画面でフローを作成ボタンを押して,データフローを作ります.フロー名を入力後,送信元に Google Analytics を指定し,先ほど控えたライアントID とクライアントシークレットを入力し,接続名を任意の名前を入力します.

f:id:sadayoshi_tada:20200522005834p:plain f:id:sadayoshi_tada:20200522005840p:plain

データの出力先の S3バケット名を指定し,フロートリガーセクションでオンデマンドで実行を選択して次のページにいきます. f:id:sadayoshi_tada:20200522005848p:plain

手動でフィールドをマッピングするを選択した状態で,マッピングする Google Analytics のデータフィールドを選択します.今回は日付と PV のデータを取りたいので Time:DIMENSION: ga:datePage Tracking: METRIC: ga:pageviewsマッピングしました.

f:id:sadayoshi_tada:20200522010337p:plain

S3 に出力確認

作成したデータフローでフローを実行すると,オンデマンドで S3 へのデータアップロードが行われます.

f:id:sadayoshi_tada:20200522010904p:plain f:id:sadayoshi_tada:20200522010915p:plain

アップロードされたデータは以下のようなファイルでアップロードされます.中身をみると,下記のJSON データになっていました.今回はオンデマンドでデータを連携しましたが,スケジュールも可能なので定期的に S3 にデータを連携して素早く分析や可視化をしていけそうです.

S3バケットに上がっているファイル f:id:sadayoshi_tada:20200522011122p:plain

データの詳細

{
  "reports": [
    {
      "columnHeader": {
        "dimensions": [
          "ga:date"
        ],
        "metricHeader": {
          "metricHeaderEntries": [
            {
              "name": "ga:pageviews",
              "type": "INTEGER"
            }
          ]
        }
      },
      "data": {
        "rows": [
          {
            "dimensions": [
              "20200512"
            ],
            "metrics": [
              {
                "values": [
                  "92"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200513"
            ],
            "metrics": [
              {
                "values": [
                  "362"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200514"
            ],
            "metrics": [
              {
                "values": [
                  "567"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200515"
            ],
            "metrics": [
              {
                "values": [
                  "275"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200516"
            ],
            "metrics": [
              {
                "values": [
                  "71"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200517"
            ],
            "metrics": [
              {
                "values": [
                  "95"
                ]
              }
            ]
          },
          {
            "dimensions": [
              "20200518"
            ],
            "metrics": [
              {
                "values": [
                  "167"
                ]
              }
            ]
          }
        ],
        "totals": [
          {
            "values": [
              "1629"
            ]
          }
        ],
        "rowCount": 7,
        "minimums": [
          {
            "values": [
              "71"
            ]
          }
        ],
        "maximums": [
          {
            "values": [
              "567"
            ]
          }
        ]
      }
    }
  ]
}

まとめ

AppFlow を使って Google Analytics のデータを S3 にアップロードすることができました.S3 にデータ置けたので次のステップとして Athena や QuickSight を使って分析と可視化も行なっていきたいです.

AWS のクラウドネイティブアーキテクチャを『クラウドネイティブファーストストーリー』で体感しよう!

タダです.

普段クラウドの仕事していて,耳にする「クラウドネイティブ」というトピックを学びたいと思って技術書典応援祭で「クラウドネイティブファーストストーリー」を購入しました.読み終えたので,本書の概要と合わせて自分が学べると感じたことを紹介します.

技術書典応援祭のページ techbookfest.org

Booth booth.pm

目次

本書の章立ては次の通りです.本編として176Pの内容です.

  • 第1章 ようこそ、クラウドネイティブの世界へ
  • 第2章 AWS で構築するクラウドネイティブサービス
  • 第3章 コンテナサービスの構築
  • 第4章 CI/CD の構築

本書で学べること

クラウドネイティブって?

本書のタイトルになっている「クラウドネイティブ」はどういった定義でしょうか? クラウドネイティブ技術の民主化と利用を促進を目的とする団体の Cloud Native Computing Foundation(CNCF)は次のように定義しています.

クラウドネイティブ技術は、パブリッククラウドプライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。

これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

github.com

つまり,「クラウドネイティブ」はクラウドインフラストラクチャの環境でスケーラブルなアプリケーションを開発していくための技術で,次が代表的なそのアプローチ例です.

  • コンテナ
  • サービスメッシュ
  • マイクロサービス
  • イミュータブルインフラストラクチャ
  • 宣言型API

クラウドネイティブアーキテクチャへのロードマップ

では,クラウドネイティブアーキテクチャへのロードマップをどのように辿っていくのがいいでしょう.参考例で CNCF では「CloudNative Landscape」というイメージが公開されており,各セクションごとのサービスも公式サイトでまとめられています.

github.com

landscape.cncf.io

上記でも触れたクラウドネイティブの定義,クラウドネイティブアーキテクチャへのアプローチとしてコンテナ,CI/CD,コンテナオーケストレーションの技術概要が1章では説明されています.コンテナ,CI/CD,コンテナオーケストレーションは「CloudNative Landscape」の10個のステップの1~3番目にあたるアプローチなので,タイトルでいうファーストストーリーにあたるのでしょう.

2章以降で AWS でコンテナ,CI/CD,コンテナオーケストレーションを実現するための設計や構築をハンズオン形式で勉強できる内容になってます.

2章以降で扱うアーキテクチャ概要

2章以降で作るアーキテクチャの概要図は次のものです.

引用元: クラウドネイティブファーストストーリー P14 図2.1より引用

サービスとして登場するものも列挙します.

  • WAF
  • ELB(ALB)
  • ECS(Fargate)
  • RDS(Aurora)
  • ECR
  • CloudWatch(CloudWatch Events/CloudWatch Alarms)
  • CloudTrail
  • Systems Manager(Parameter Store)
  • S3
  • Cloud9
  • CodePipeline
  • CodeCommit
  • CodeBuild
  • CodeDeploy

読了後の所感

本書を読了して,メインのトピックであるコンテナ,CI/CD,コンテナオーケストレーションAWS で扱うためにサービスの概要や設計の観点を抑えながら画面キャプチャ付きで解説がなされていて初めてサービスを触る人にも丁寧な内容だと感じました.僕は本書で扱うサービスを業務や趣味の時間で触れていたのですが,全く触れてないサービスをドキュメント見ながら行うより具体的なイメージがあるととっつきやすいです.

個人的に 4章 の CI/CD を運用していくためのアカウントをどう分けるか,デプロイを各ステージでどう評価して次のステージに進む条件とするか,切り戻しをどうするかといった実際のノウハウが詰まっており,普段CI/CD を管理することがないためとても実践的なナレッジを学ぶことができました.4章は何度も読み直したいと思います.

本書で扱いませんでしたが,このアーキテクチャを Infrastructure as Code 化して横展開したり,CI/CD の中でモックを展開するための一時的な環境を構築するケースもあるかと思います.環境を作って壊してを迅速に行なって品質評価やリリースまでにスピードをあげるために必要なトピックかと思うので,本書のインフラのコード化をやってみるのも良いかと感じています.

そして,著者の@msy78さんと@HorseVictoryさんの発表資料が JAWS DAYS で公開されていました.本書の内容と重なる部分もありますので,合わせてチェックしておくと良いと思いました. speakerdeck.com

NEXT STEP: クラウドネイティブの勉強をより深くしよう

本書を読んだ後にさらに勉強を進めていくためにオススメの教材を紹介します.

クラウドスターターキット

本書同様に AWSクラウドネイティブのアーキテクチャを構築しながら技術を学ぶコンテンツとして @_y_ohgiさんが公開している「クラウドスターターキット」があります.Terraform を使って環境構築し,コンテナで動作する Golang アプリをデプロイするハンズオンになっています.本書では扱っていない Infrastructure as Code や監視,SLI/SLO にも触れられており,想定はソースコードを Fork して本番環境に適用することであるため実践的な内容です.これが無償で公開されているなんて神かな?と思えます.

y-ohgi.com

blog.y-ohgi.com

クラウドネイティブ・アーキテクチャ 可用性と費用対効果を極める次世代設計の原則

クラウドネイティブアーキテクチャを実現していくためのスケーラビリティ,セキュリティ,コストの最適化,運用といった技術と組織で活用していくためのトピックが扱われた書籍だと感じています.プラットフォームが AWS だけでなく,Azure,GCP の内容を含んでいるため,AWS 以外のプラットフォームもしくマルチクラウドの業務に当たっている人にもヒットすると思います.自分も読めてないので読んでみたいです.

Kubernetes で実践するクラウドネイティブ DevOps

CloudNatice Landscape でいうコンテナ,CI/CD,オーケストレーションやオブザーバビリティの部分を扱う書籍だと思います.Kubernetes の基本から始まり,クラウドネイティブでサービスを構成・移行・運用していくための勉強ができるのかなと思って僕も読んでみたいと思っている一冊です.

Kubernetesの基本から、継続的デプロイ、機密情報管理、オブザーバビリティなどの高度なトピックを扱う本書は、サーバ、アプリケーション、サービスを管理するIT運用者、クラウドネイティブサービスの構築や移行を行う開発者必携の一冊です。

Kubernetesで実践するクラウドネイティブDevOps

Kubernetesで実践するクラウドネイティブDevOps

Try Envoy

サービスプロキシのトピックで Envoy があります.その勉強としてやってみたいと思っているのが「Try Envoy」です.kakakakakku(id:kakku22)さんが紹介されていて気になっていたので,今後勉強したいと考えています.

www.envoyproxy.io

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

まとめ

クラウドネイティブファーストストーリー」で学べること,所感を整理しました.日本でもクラウドをシステム基盤に採用する事例が増えてきて,デファクトスタンダードになりつつあると感じています.そんな潮流でクラウドに乗せた後の環境を最適化するのはクラウドのメリットを得るために推進していくべきですが,AWSクラウドネイティブアーキテクチャを構成していくため設計や構築のポイントを勉強したい人にとってオススメの一冊だと思いました!

AWS のサービスステータスを Datadog で監視する『AWS Outage Alerts』機能

タダです.

AWS の障害が発生した時に感知するためにService Health DashboardRSS 情報を見る方法があります.ただ,監視システムでサービスステータスを統合管理できたら運用しやすいかと思います.自分が業務で使っている Datadog で AWS のサービスステータスを監視できないかを調査・検証したのでこの記事でまとめていきます.

AWS のサービスステータスを Datadog で監視する方法

Datadog での AWS サービスステータスを監視するための方法が公式ブログで紹介されていました.「AWS Outage Alerts」を使うことでサービスステータスを監視し,ステータスに変化があるとアラート通知ができる仕組みです. この機能は Datadog がService Health Dashboardのステータスをチェックして実現しています.

www.datadoghq.com

監視の設定方法

Datadog で「AWS Outage Alerts」をどう設定していくかを見ていきます.はじめにモニターを新規で作成する際にIntegrationを選びます.

f:id:sadayoshi_tada:20200515012912p:plain

次に,Integration選択後,Installed タブを選んで AWS のアイコンを選択します.

f:id:sadayoshi_tada:20200515013224p:plain

続いて,モニターの詳細を設定していきます.Integration Status タブを開きまず①のPick monitor scopeのセクションで監視したいリージョンとサービスを選択します.次に,②のSet alert conditionsセクションでアラートの条件を設定するのですが,デフォルトの1回のチェックが失敗したらすぐアラートを発報するようにするのがおすすめ設定です.

f:id:sadayoshi_tada:20200515013612p:plain

そして,アラートの通知の設定です.アラート通知文で指定している{{region.name}}はアラートの発生したリージョン名を,{{service.name}}はアラートの発生したサービス名を通知する変数として使えます.通知先を指定後テスト通知してみます.

f:id:sadayoshi_tada:20200515013628p:plain

テスト通知でメールを送信した結果,テストでは「us-east-2 の EC2」で障害が発生したとした場合のアラートが飛んでくることを確認できました.メールで通知しましたが Slack にも通知可能です.

f:id:sadayoshi_tada:20200515014259p:plain

まとめ

Datadog での AWS 障害を通知するための機能の紹介と設定方法を検証したので紹介しました.通常サービスのプロセスやリソース監視はやられていると思うのですが,AWS のサービスステータスも「AWS Outage Alerts」機能で監視を行うことができそうなのでこの機能をどう運用していくかも検討してまた記事化していきます.