マイクロサービスを支えるインフラストラクチャ

1. 現状のシステム構成分析

インフラ

• AWS が推奨するシステム設定がされているか
• データ分析のための基盤が整備されているか（アプリログなどを一元管理しているか）
• リソース監視が適切か（アラート通知がちゃんと設計されているか？）

アプリケーション

• AWS に適した設計家？
• DRY 原則が守られているか？
• スケールしやすいか？
• SQL アンチパターンの検証。
• コードレビュ、テストのポリシー
• Git の運用、CI/CD

2.アーキテクチャの再構成

• Terraform
• API Gateway
• Open API
• Cognito
• DynamoDB

AWS Well-architected を確認。

• データのアクセスパターンを考慮しているか。
• 疎結合なアーキテクチャーが採用されているか。
• ネットワーク設定について、構成管理ツールを使って自動化しているか。 などなど。

Well-architected tool を使って、上記の内容を細かくチェック。

• すべての項目に法る必要はなく、適合しないケースについてのリスクや改善点を把握。
• レビューを定期的に行うことで、より優れた設計へと進化できる。

Twelve Factor App

• 特定のプログラミング言語やインフラに依存せずに適用することができる。
• 現在のアーキテクチャのそぐわないものも出てきている。 →Beyond the Twelve Factor appが更新版のもの。

SAP: Strangler Application Pattern もある。

例:

• ALB のパスベースルーティングで、旧環境(/v1)と新環境(/v2)を並行運用。

3. データベースの再設計

• テーブルの正規化
• 共有データベースの分離

4. インフラの再設計

• TerraForm による構成管理を採用。

• ほぼ全てのインフラリソースをコード管理（Github, AWS, DataDog） リソースの変更を Github Issue ベースで管理できる。

• VPC の設計（開発・ステージング・本番）開発からステージングへの接続などができないように。

• 管理 VPC：踏み台サーバ

• 利用サービス: API Gateway, DynamoDB, Cognito など

5. アプリケーションの再設計

• API ファースト開発
• API Gateway、サービスディスカバリ、フェデレーション ID、集約ログなど

認証基盤

• Amazone Cognito の採用（認証のエンドポイントを統一するため。OAuth2, SAML2.0 などが使える）
• 認証の設計をする必要がないので、開発に集中できる。

AWS Amplify -> Cognito -> Lambda -> RDS -> Lambda -> React(JWT) -> cloudFront -> API Gateway 将来的には、Lambda と RDS が要らなくなる。

メッセージ基盤

• DynamoDB: 高スケーラビリティ
• API Gateway -> ECS -> DynamoDB

ECS

• コンテナオーケストレーション
• Fargate によるインスタンス管理でフルマネージド。
• Fluent でログを集約、エラー時は Slack に通知。
• ログの可視化に Kibana。
• 整形したログを ElasticSearch を使用。
• AWS Cloud Map（サービスディスカバリの活用）。コンテナの名前解決を自動化。コンテナ間の連携が容易に。
• サービス間は API で通信し、機能単位で分離。
• すべてのログを集約化。

Fargate

• SSH ができない（メモリリークの問題が発生したときの調査が難しい）。
• ログドライバが Fluentd のドライバをサポートしてない（AWS Fire なんとかで可能に）。

セキュリティ

• セキュリティオートメーションツールを使用。
• AWS WAF, Guard Duty, Trusted Advisor, CLoudTrail, config の有効化, Inspector の使用。

インフラのイベント監視

• 各種サービスから出力されるログを Lambda で分析（AWF, Guard Duty などのイベントを設定し、Slack に通知）。

構成管理の応用事例

• Capy パズル CHAPTER(パズルを当てはめての認証)
• TerraForm, Serverless Framework

サーバーレスで作るモバイルアプリ向け Backend For Frontend（Timmer）

BackGround

人類が昔から今に至るまで変わらない価値観はなにか？そういった事業をやる。→ 家族 トレンドの追っかけっこにならないように。

内容

課題解決のための技術選択のケーススタディ

サーバ側 １リソースにアクセスする１つの API に整理できるのが望ましい。 Videos, Photos。。。

クライアント側 あわよくば、１画面を構成するのに、１つの API コールで済ませたい。 複数の情報を１つにまとめてコールできたほうが楽（サーバ側からすると、API がカオスになる）。 Videos+Photos。。。

課題

• サーバ PAPI が複雑化。
• 複雑な API を扱うビジネスロジックの分散化

1. 品質管理の徹底

• 自動テスト（Unit Test, UI Test）の網羅によりデグレを防ぐ。
• API 修正のたびに過去バージョンも考慮した手動テストを行う。

無理がある。

2. ネイティブでコード共有

• Kotline/Native で iOS/Android ともに利用できるビジネスロジックをライブラリ化する案
• 整理する必要なことが多い（技術調査コスト、共有ライブラリ修正時の CI フローの検討）。

一部有効かもしれないが、コストが高い割に完全に幸せにならない。

3. API に表示ロジックを寄せる

• API の方で i18n の対応、文言や UI 表示の出し分け処理をやる必要がある。
• クライアント側は受け取ったデータを表示するだけの View になるから、シンプルになる。
• サーバ API でテストを充実させていれば品質担保も可能。

片方の課題しか解決できていない。 日付整形、サーバ側でやることが一気に増える。 サーバエンジニアの責任の範囲がさらに増えていく方向に進んでしまう。

BFF

定義：１つのユーザ体験に密結合なバックエンド

• クライアントとバックエンドのサービス間に挟まる API 層
• クライアントは直接バックエンドサービスを叩かずに BFF を叩く。
• BFF はクライアントの要件に合わせて最適化する。

ここでは、BFF は、API Gateway 的なアーキテクチャとして捉える。

クライアント <-> BFF <-> API サーバ

BFF はクライアントサイドが管理する（責務の切り分け、クライアントが自分に都合の良い API を作成）。

BFF の責務

責任の分離

• クライアントごとに都合の良い密結合な API 層を用意することで、責務の分離を行う（例. Netflix）。
• Moblie, Web Desktop などに合わせて、BFF を作成。

集約と変換

• 様々なバックエンドサービスと通信してデータ集約
• データをクライアントに適した形に変換
• クライアントは BFF とだけ通信すれば、集約済みのデータ（使いやすいデータ）を使える。
• マイクロサービスに最適。

ユースケース

• iOS, Android の間で分散している BL の集約化ができる。

BFF の導入

• TypeScript を採用（Lambda など他は Go を使ってる）。

• API Gateway: サーバレスの API 作る。

• Serverless Framework: 構成管理・デプロイ周り

• Lambda は１つの Express アプリケーションで複数エンドポイントをハンドリングするように。 →Lambda を増やしすぎると管理しきれないため。

• 本来、あまりきれいでないかも。生産性・管理しやすさ・今後増えるであろうエンドポイント数の規模を考えても妥当と判断。

BackEnd: EC2 - ELB BFF: Lambda(Express), API Gateway

認可と認証

• API Gateway の API key とともに Backend API 用のトークンもリクエストで渡している。 → 課題がある。密結合。

テスト

• Jest
• CircleCI 経由で実行。
• Serverless CLI の deploy コマンドがあるので、CI も簡単に構築（CircleCI の IAM 設定を忘れずに）。

課題

• VPC 内で通信を完結させるなどして速度の最適化を行いたい。
• 認証認可の課題解決。

伝えたいこと

• 自分のチーム・プロダクトに合わせた技術選択を（なんの課題を解決したいのか、その場合、それを解決する技術はなにか？）。
• 未来の課題を想像して、いま、その課題の解決を今のうちに解決したほうがいいのか考える（１０歩先の、１，２歩先の課題もどこまで解決するのか）。

よくある課題を一気に解説、御社の技術レベルがアップする 2019 秋期講習

1. コンテナの CI/CD ちゃんとしたい

本当にしたいこと

• 開発速度を上げ、プロダクトの活を向上させたい。
• テストをちゃんと行い、プロダクトのクオリティを上げたい。
• 自動化しつつも状況の把握やロールバック等のハンドリングを適切に行いたい。

思考フロー

1. 手作業でのデプロイと決別する。

• パイプライン以外での構成変更やデプロイを認めない。
• 手作業での変更を行わないためにどうすべきかという思考を持つこと。

2. リビジョンとデプロイメントを連動させることを考えよう

• リビジョンを一位に特定する要素（リビジョン番号（コミットハッシュ値、推奨）、タグ、リリースバージョン）を使う。 →Git のコミットハッシュ値を、Docker の Version のタグ（Nginx:xxx）と連動させる。 →K8s なら、YAML ファイルのリビジョンと連動。

利点

• 本番やステージングなどの環境によらず、一意なコード・コンテナを利用できるようになる。
• ロールバックが用意になる。

コードベースとアプリケーションの間に、常に１対１の関係をもたせる（12 Factor apps でも言及）。

3. マネージドサービスを中心にパイプラインを考えよう。

• 開発の効率化、クオリティの向上（CI/CD 環境自体の管理運用コストをできるだけ抑える）。
• AWS CodeBuild, ECR, ECS など。
• CodePipeline で CI/CD の全体を管理。CodeBuild で個別にやらずに一元管理。

2. ログってどう設計すればいいの

やりたいこと

• サービス・アプリケーションの状況を把握したい。
• 目的に応じて可視化したい。

思考フロー

• ログの種類と目的を考えよう。
• ログの設計をしよう。
• アプリケーションに合ったフォーマットを考える。

1. ログの種類と目的を考えよう

• ログの種類と用途を考えるところから始める。
• 用途に合ったものが出力されているか？ログが多すぎて、重要な情報が埋もれてしまっていないか？
• 秘匿性の高いものが表示されていないか？（ID/Pass、メールアドレスなど）

2. ログの設計をしよう

• ログレベル（Info, Warning, Error）（Dev, Test, Prod）を検討。
• 出力先：運用者がすぐに見つけられることを出力する。出力先のルールぎめ。ログの集約しやすいように（CloudWatch、S3 など）
• 権限：適切なログの権限なのか。ログの内容が見られて OK なものなのか？

3. アプリケーションに合ったフォーマットを考える

• ログの内容が十分なのか？どういったデバイスから接続しているのか、ポートはどうか。 →Nginx のデフォルトのログ内容だと少なすぎる。

3. いい感じの機械学習基盤を作りたい

やりたいこと

• ユーザーの価値を届けつつ運用負荷を減らしたい。
• 属人化させず、再現性を担保。パフォーマンスももちろん大切。
• スケーラブルな機械学習基盤を作って、プロダクトの継続的な価値向上につなげたい。

思考フロー

• できる限りマネージドサービスを使う。
• どこまで自由度を求めるのか。
• ワークフローの構築と自動化を考える。

1. できる限りマネージドサービスを使えないか考えよう

• AI サービス：トレーニング済みのデータを使える。画像認識、顔認識、不適切コンテンツの検出、OCR、音声、自動言語処理、チャットボット
• ML サービス：Amazone SageMaker 上で学習からデプロイまで一元管理。対応しているフレームワークが決まっている。

2. どこまで自由度を求めるのか

• データだけ準備
• モデルも自分で書く
• コンテナ持ち込み

AutoML：レコメンドのためのサービスなどが用意されているので、コードレスで学習も可能。

3. ワークフローの構築と自動化を考えよう

• データだけ用意してビルトインアルゴリズムを実行。

S3 -> AWS Glue -> S3 SageMaker -> S3 -> ....

4. セキュリティを自動化するにはどうすればいいのか？

やりたいこと

• 効率よく過不足なくセキュリティに取り組みたい。
• セキュアなシステムで事業とユーザーを守りたい。

思考フロー

• マネージドサービスを使う。
• キャッチすべきアラートやイベントを決めよう。
• イベントに対するレスポンスを考えよう。

1. マネージドサービスを使う

• 自分の責任範囲を小さくする（抽象度が高いサービスを使うことで、セキュリティを担保しなければならない範囲が小さくなっていく。ただし、自由度は下がる）。
• セキュリティ系マネージドサービスで低コストに高機能を得る（GuardDuty(400 ぐらいのパターンを検知。AWS Security Hub+CloudWatch Events で自動化), CloudTrail, AWS Config）。

2. キャッチすべきアラートやイベントを決めよう

• 何を検知できるのか、発生時に同影響があるか考える。

3. イベントに対するレスポンスを考えよう

• CloudWatch Events を起点に必要なアクションに連携。Amazone SNS で管理者に通知できる。
• もしくは、Lambda+AWS Step Function で Attacker を Ban するとか。

AWS 活用ですすむ地方/中小企業のゲームチェンジ

1. Web 案件

• 割り切ってシングル構成も多い
• AWS に移行しただけで、レンタルサーバーよりも早くなった。
• EC2/t3 インスタンス 1 つで構築。
• CloudFlare は無料枠があるので、あえて使った。

2. サーバレス案件での AWS 活用

• 新規サービスの提供で活用（スモールスタート出始めたい場合）。
• 不定期に発生する業務のために肯定的なコストを掛けたくない。

S3 -> Lambda -> S3 -> SNS -> SES でメール通知

API Gateway -> Lambda -> DynamoDB + 外部 API にアクセス

3. IoT・機械学習案件での AWS 活用

• 写真の振り分けを Rekognition が行い、顔ごと似社員の振り分けを実行するシステムを構築（ハンズオンで 1 時間でできるやつ）。

S3 -> Rekognition に顔登録 -> DynamoDB に名前と顔 ID を登録 -> Lambda で実行

• センサーデータを FireHose でまとめて、SageMaker に渡して機械学習による異常検知システムを動かす。
• アルゴリズムはビルトインのものを使って良い制度を実現。自分たちで 1 から実装する必要なし。
• Step Function で Lambda の実行フローをまとめている。

IoT Core - Knesis Data Firehose - S3 - Lambda - RDS - ES2 で可視化

Nature Remo の裏側　 AWS と Web 技術を IoT の世界でフル活用する

チャットでも使われるリアルタイムの双方向の通信を可能にするシンプルなアーキテクチャ HTTP API -> AWS -> WebSocket -> Nature Remo

ECS

• Worker
• API -> redis(pub/sub) -> Stream |-> RDS
• Stream(WebSocket)

Go での Web アプリ（API）

• Gorilla web toolkit を部分的に使用。
• gorp/redigo を最近使い始めた。
• DynamoDB も使い始めた。

ECS とコンテナ活用

DependerBot

• go mod tidy も使う。

AWS Amplify Framework の挙動を解説する

抽象度が高いフレームワーク。スタートアップで速攻で開発したい場合に利用？

なぜ Amplify が必要なのか？

一般的な Web/モバイルアプリの構成要素

• 認証認可、メッセージング、冗長化などは、差別化要因ではない。
• ログ収集、プッシュ通知送信、ユーザー間のリアルタイムチャット・メッセージング、クライアントイベント収集、分析業務、他システム連携

Amplify が解決。

• やりたいことから直感的にサーバレスなバックエンドを構築
• バックエンドの功徳はシンプルなコマンドで実行できる。
• スケーラビリティも考慮。

Amplify CLI

• TypeScript で実装。

• amplify addで色々なサービスを追加できる。

• amplify serve|run: ローカルでサーバを建てることができる。DynamoDB もローカルで行ける。Node.js とか。

• amplify push: ローカル情報をクラウドにデプロイできる。

• amplify codegen: GraphQL スキーマオブジェクトを生成。

• amplify env: dev, prod などの複数環境を管理する。

init > add > push

• amplify init: プロジェクトの初期化、CloudFormation とか他のプロバイダーにも対応。

• IAM ロールや CloudFormation とかをよしなに作ってくれる。

• 結果を、/src/aws-exports.js に書き出す。

• amplify add: サービス追加。IAM 認証が必要なものは、選択によって追加される。

• amplify push: 環境をデプロイ。

View コンポーネント（Amplify Framework）

クラウドに接続された UI フレームワークやライブラリを使い、フロントエンドアプリを開発。 AWS SDK を導入する必要があるのに対し、Amplify では専用のコンポーネントを導入するだけで、認証画面が作られる（React や Vue に対応）。 → 認証認可について、自分で作り込む必要がない。

各コンポーネントの実装は Github に公開されている。カスタマイズ性に優れる。 vue だと 98 行のシンプルな実装になっている。i18n にも対応している。

AWS Amplify のはじめかた

公式のチュートリアルがある。 AWS Loft 　「怠惰なプログラマー向けの。。。」ハンズオンをやってみるといい。

レガシーコードからの脱却

Joy.inc

レガシーコードとは？

• レガシーコードとはテストのないコード
• 保守または拡張が困難なコード

コードの品質が重要ではなく、コードがどのような機能をするかに注目してしまったことによって生まれる。

使われるソフトウェア

• 変更が必要になる。必要な変更をすべて予測するのは困難。
• よって、変更可能となるように書くべき。 → その逆が、レガシーコードとなる。
• 必要になったときに対応できるエンジニアリングプラクティスを身につける。
• そもそもソフトウェアの保守コストを下げたい。

リリース後のバグ修正には、とてつもない時間がかかる。 → あとから見つかるほど、じかんがかかるもの。

開発者の時間の半分以上は、過去にやった仕事の手直し → コードを扱いやすくすることで保守コストを下げよう。

コードを最初から変更可能となるように書く

ソフトウェアが生み出す成果を決める要素

• 問題設定力
• 開発力
• チーム力

レガシーコードを最初から書かないようにするにはどうしたらいいのか？

• やり方より先に、目的、理由、誰のためかを伝える。
• 小さなバッチで作る。
• 継続的に統合する。
• 協力し合う。
• CLEAN コードを作る。
• まずテストを書く。
• テストで振る舞いを例示する。
• 設計は最後に行う。
• レガシーコードをリファクタリングする。

各項目は相互に関連性がある。

1. やり方より先に、目的、理由、誰のためかを伝える

• プロダクトオーナー：What をやる。何をやるのか？

• 開発者：HOW をやる。どうやって実装する。

  役割の違いを明確にする。

物事のやり方は多種多様あって、トレードオフがある。 やり方を明示されると選択や交渉の余地がなくなる。 結果として手続き的なコードになりがち（IF 文の多くなる） → お互いコミュニケーションをとって、無駄な時間や機能を減らす。

ユーザストーリー 何が、なんのために、誰のために、存在するかを１文にまとめる。

• 機能について会話できるくらいのかろうじて十分なドキュメント（仕様書ではない）
• 会話によってソフトウェアを作るための理解を深める。
• 知識は詳細なドキュメントではなく、コードやテストにまとめるべき
• ユーザストーリーが限定的であることでテストしやすくなる。
• 実例によるテストが可能になる。
• シンプルに初めて、追加はあとからできるようにする（MVP、小さなバッチで作る）。

漸進的にすすめることで、良い設計が浮かび上がってくる。 どんな課題を解決したいのかをしっかりと定義して、認識合わせることが一番重要。

2. 小さなバッチを作る

タイムボックスとスコープボックス

• タイムボックス：固定の時間で仕事をすすめる。タスクの分割になれるまでは機能しやすい。スクラム、XP。
• スコープボックス：ストーリーやタスク単位で作業を終わらせる。作業単位が均一のものはよい。カンバン。

QCDS の何を調整するのか

• スコープと時間を柔軟に考える（品質を満たせなければ意味がないので、品質を守る分、作れる範囲を絞る）
• リソースという単語は人間には適用できない（人月難しい）。
• 人が増えると、コミュニケーションコストが増えて、速度落ちる。→ 同一の人を絞る。
• 品質を犠牲にすると、あとから辛くなる。

スコープを調整し、価値ある機能から順番に作り、価値を最大化する

ケイデンス、リソース・プロセス効率化

• リズムが長くなると、リソース効率化を目指しやすい。
• リズムを短くすると、プロセス効率があがる。同時にやるものをへらす。

プロセス内の作業量をへらすと、システムが効率化する → モブプログラミングで、１つずつ全員でやり続ける。待ち時間がなくなる。 → 稼働率が２０％になっているように見えるが、コードレビューをその場でやっているから、あとにかかるコストを削減している。

ソフトウェアの評価

• 顧客にとって価値あるものに基づいて評価すべき。
• 価値は完成して初めて価値になる。
• 一個ずつ完成するほうが、価値が高い。
• 価値の実現までの時間が期待したとおりか？
• サービスとして成果が出ているかに着目して評価されるべき。

フィードバックサイクル

• 小さなバッチのほうがフィードバックの回数は増える。
• 変化を受け入れる文化の醸成。

5. CLEAN コードを作る

• 良いコードとはなにか、認識合わせを行う。
• 一方で、従うべきガイドラインも必要。

凝集性

• クラスが１つの責任に集中する
• つまり名前をつけられるアイデアや概念になる（名前重要）。

data, check ってなんのデータなのか、何をチェックしているのか、具体的にいい名前を決めること。 自然言語に近い形で、コードが書かれているべき。

疎結合

• サービスを直接呼び出すのではなく、中間層を経由する。
• 何でもできる API とはまずい。
• 再利用という名目のもとにコードの品質を犠牲にしてはいけない

カプセル化

• インターフェイスと実装を分離する。
• アウトサイドインプログラミング
• 使用者の観点で機能を設計する。

断定的

• オブジェクトがフィールドをもつから、それらを管理するメソッドを自身が持つべき。

冗長性をなくす

• DRY 原則

AppSync ユースケース/デザインパターン

1. GraphQL について

• GraphQL API 用のクエリ言語
• 定義に従ってクエリを書き、サーバから JSON 形式のデータを取得する。
• Subscription, Mutation, Query

スキーマ定義

• Not null は「!」で表現。

Query

• スキーマとモデルに対して、クライアント側でレスポンス形式（欲しいデータ）を指定する。一分のデータのみの取得が可能。
• 必要なときに、必要なデータのみを抽出できる。

Mutation

• 追加更新削除（変更）をまとめたもの

Subscription（特徴的な機能！）

• Mutation で定義されたイベントをトリガーにして、事前定義された Subscription の処理が実行される。

API インターフェイス

REST API：１つの API が１つのエンドポイントを持つ。 GraphQL：エンドポイントは常に１つ。その後ろに API がカプセル化されているイメージ。

2. AWS AppSync

• GraphQL のマネージドサービス。

• アカウントのデータサービスに接続。

• データ同期、リアルタイム性、オフライン処理（オンライン担った瞬間に、まとめてデータ取得できるなど）。

• 強豪の検出と解決。

• セキュリティ

• AWS App Sync Client：認証、オフラインロジックなどを含んだ Client

• Resolver：リクエスト・レスポンスの処理を記述する関数

• Data Source：DynamoDB、Lambda、Aurora Serverless、ElasticSearch、HTTP Endpoint（REST API つなぐ）

利用ケース

• リアルタイム：最新の情報を見るダッシュボード。リアルタイムなデータ更新。
• コラボレーション：複数のユーザが共同編集するアプリケーション、
• ソーシャルメディア：SNS やチャット。オフラインでもアプリケーションを操作でき、再接続時に自動 Sync できる。

モバイルだけでなく、様々なケースに利用可能。 リクエスト・レスポンスの Resolver

1 つの Mutation に対して、SubScruotion を実行。 １つのユーザが AppSync に更新処理（Mutation）を行った後、SubScruotion で他のユーザ似データがリアルタイムに反映される。

Request Mapping Template

必要となる処理ロジックを VTL（Velocity Template Language）で技術。

3. AWS AppSync のユースケース・デザインパターン

AppSync -> DynamoDB（鉄板構成）

Schema ジェネレート機能の利用

• 既存の DynamoDB テーブルから Schema 定義を生成できる。

AppSync で全文検索

更新までやる。データソースが１つになるのはバットプラクティス？ AppSync -> DynamoDB, ElasticSearch

AppSync で既存 API または他 SaaS API との連携

海外だとあまりない？ Lambda + HTTP Endpoint の組み合わせ レスポンスを Lambda で変換。

関連する複数の処理を１つの API にまとめたい

Pipline Resolver を使って、複数の API を実行できる。

GraphQL API の Version 管理

• REST とは別の思想で Versionless API を推奨。
• バージョン管理は推奨していない。フィールドを増やしていく。

GraphQL の SubScription のフィルタリング

SubScription で引数を使用して特定のユーザのみの画面を更新（Subscription を発行する）。

スキーマフィールドの認証タイプを使い分けたい

• 社内外で、開発系・本番系で認証方式を変えたい。
• AppSync 　 Multi-OAuth

GraphQL API に実行権限をつけたい

• 管理者飲みが使える API と分けたい。
• Cognito グループで API を叩けるかどうか分けることがスキーマ定義として可能。

GraphQL のパフィーマンス・状態の可視化

• CloudWatch Insights への連携が可能。AWS の判定基準に合わせて、見れる。
• ElasticSearch や Kibana との連携が可能。

VTL

4. まとめ