kglabo.blog

I will output what I thought.

「AWS Summit 2019」に参加してきました(3日目)#AWSSummit

どうもみなさん、おはこんばんにちわ!
ミナカワ(@yu_kgr)です。

2019/6/12 〜2019/6/14 に「AWS Summit 2019」というイベントがあり、AWSに対する理解を深めたかったので参加してきました。
当エントリはそのイベントの参加レポート(3日目)になります。

f:id:kgr0210:20190615022802p:plain

#13. AWS コンテナサービス入門

  • 登壇者(敬称略) : 原 康紘(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : コンテナオーケストレーションサービスである Amazon ECS / Amazon EKS、フルマネージドなコンテナ実行環境 AWS Fargate、コンテナイメージレジストリの Amazon ECR に代表される各サービスの特徴と、これらがなぜ必要なのかをお話しいただきました。

概要

このセッションで解説した内容は大きく分けて下記。

  • 解決したい課題の理解
  • コンテナを活用したい場合、何をどのように選択すればよいのか

コンテナとは

ここで言う「コンテナ」とは主に、Linux Containerについての話

アプリケーションを構築するコンポーネントとしては、

  • アプリケーションコード(ここがよく意識される)
  • ランタイム / エンジン
  • 依存ライブラリ / パッケージ
  • 設定

という感じで、実行環境は、

  • ローカル / ラップトップ(開発環境)
  • ステージング / QA環境
  • 本番環境

という形が考えられるが、開発環境やローカルだとモックを用意して実行することになると思う。
この状況をJavaで例えると「環境によってJVMで設定管理。しかし環境によってはバージョンが異なる」みたいな事が多々おきてしまう。

こういった環境に出る差異の解決策としてコンテナが存在している。

上記の例だと「設定」以外をコンテナに格納する。

  • 設定をコンテナ内にいれると、環境用のコンテナが出来てしまうので入れない
  • 設定は実行時に環境変数として渡す事が多い

そして、こういったコンテナのデファクタなのが「Docker」で、Dockerエンジンと必要なコンテナを用意すれば環境を用意できる。

  • 考え方としては「Dockerエンジンを各環境(dev/stg/prd)に用意」する

Dockerと仮想マシンの違い

Dockerは仮想マシンと比較される事が多い。

  • 「Dockerは軽量だよね」
  • 「仮想マシンとDockerは似てるよね」

なぜ比較されやすいのか言うと、

  • EC2の場合、AMIを指定するとインスタンスが生成
  • Dockerの場合、イメージを指定するとコンテナが生成

というように工程が似ているため、まるで軽量な仮想マシンだと思われがちだが、

  • 「仮想マシンは”マシン”であり、コンテナは”プロセス”である」
  • つまりコンテナはアプリケーションのプロセスに焦点が当てられているので、プロセス同士を相互作用させる場合は後述のオーケストレーションサービスを活用する。
    • 厳密に言うと、実行環境を隔離している / プロセスをアイソレーションしているので実行が早い(ここらへんは細かい話しになるので割愛)

コンテナのワークフロー

基本的なワークフローだと下記のような形となる。

コンテナイメージを作る
  1. Dockerfileを作成して「docker build(コンテナイメージが作成される)」
  2. 「docker run」を実行した後、コンテナ内で作業を行い「docker commit(コンテナイメージ作成)」
  3. 「docker push」でイメージレジストリに追加
コンテナを実行する
  1. sshでサーバに接続する
  2. 「docker run」を実行
  3. 「ducker pull」でサーバにdockerイメージを追加していく

コンテナの実行は意外とめんどくさい。

なぜなら「Docker」自体の役割は「同一サーバ上のコンテナライフサイクル管理」なのでその部分を楽するには「コンテナオーケストレーションツール」が必要となってくる。

コンテナオーケストレーションの登場

手作業でのコンテナイメージのダウンロードは非効率かつオペレーションミスが発生してしまうのでAWSの場合は「Amazon Elastic Container Service (ECS )」を利用する (AWS以外のものだとswarm / docker composeなど)

Amazon Elastic Container Service(ECS)_

このECSのAPIをコールすると、サーバ内での作業を任せる事ができる

  • クラスタでコンテナを実行したい(API)
    • 3つのAZに分散して実行してLBに接続してくださいという指示を出せる

このECSは2014年にリリースされたが、この当時はDockerを本番で動かすサービスは存在していなかったとの事。

ECSの特徴としては、

  • AWSのサービスなので他のマネージドサービスと高度な連携可能。
  • スケーラビリティ
  • 「タスク」と「サービス」を学べはすぐに利用できる
  • Linux以外にもwindowsコンテナも対応している
    • Windowsサーバ2019も先日正式対応した

Amazon Elastic Container Service For Kubernetes(EKS)

OSSのオーケストレーションツールであるk8sに対応したものも存在する。

もともと、OSSを好むお客様がk8sを利用していたが「運用難易度が高いのでAWSで管理運用してくれ」という要望があり、2017年にEKSをリリース。

  • それまで世界のk8sユーザの51%がAWS上で運用していた。

どのサーバにどれぐらいのリソースが空いていて…というようなコントロールブレーンをAWS側で提供している。

EKSの特徴としては、

  • 運用難易度が高い
    • 自分で構築してみると難しさがわかるのでやってみるのがよいとの事
  • OSSのエコシステムがそのまま利用できる
  • 各種AWSサービスと連携が容易
  • EKSサービスチーム、OSSチームがk8sコミュニティに貢献している
  • OSSなので、エンドユーザーがPRを投げて直す事が可能
  • こちらは「pod」「Deployment」「Service」「job」などのリソースに代表される高い表現力がある

イメージレジストリ

イメージは「イメージレジストリ」からDLしなければならないがどのような種類があるかというと、

  • Docker公式の「DockerHub」

    • これはアメリカに存在
    • Docker CLIから利用可能
  • AWSではAmazon Elastic Container Registry (ECR) というサービスがある

    • 東京リージョンがあるのでレイテンシ面で有利
    • セキュアかつIAM連携
    • スケーラブルかつ高い可用性
    • 公式と同様にDocker CLIから利用可能
    • ECS / EKS / k8sだけではなくもコンテナオーケストレータで利用可能

コンテナ実行環境

コンテナ実行環境とは、実際にコンテナが走っている箇所のこと。

  • EC2インスタンスの運用業務
  • OSやエージェントのパッチ・更新
  • スケーリング

といった対処が必要となってくるが、
これらを対処するマネージドサービスとして「AWS Fargate」というものがある。

特徴として下記が挙げられる。

  • AWSのフルマネージド
  • コンテナネイティブ
  • AWSサービスとの連携

ECS & Fargateの構成だと開発者は管理・運用を考えずに済むので、コンテナしか見なくて良くなる。

  • ちなみにこれもお客様から「クラスタの子守はしたくない」という要望があったから生まれたサービスだったりする。

その他コンテナ関連サービス

Cloud Map
  • 全てのCloudリソースのためのサービスディスカバリ
  • 名前解決 .comみたいな名前をIPアドレスに換えるもの
    • AWS LambdaはIPで指定されるのではなくARLで管理されるのでDNSでは名前解決できないSQNとかDynamoとかを名前解決できる
App Mesh
  • アプリケーションレベルのネットワーク(サービスメッシュ)
CloudWatch Container insight(パブリックプレビュー)
  • EKSとK8s用のinsight
  • ECS、Fargateサポートはベータ申し込み中

現実世界のコンテナワークロードはどうなっているのか

パラメーターストアであったり色々と必要になってくる。

Lambdaは「運用コストが低いかわりにアプリケーションの制約がある」 仮想マシンは「コントロールl範囲が大きいが管理コストが掛かる」

コンテナは上記2点の間に存在するものになる。

まとめ

AWSでコンテナを活用したい場合のサービスとしては、下記のものが登場する。
適時ニーズに合わせた選択を行うこと。

  • オーケストレーションツール(ECS/EKS)
  • イメージレジストリ(ECR)
  • ホスティング(EC2 / Fargate)
  • アプリケーションレベル(AppMesh / Cloud Map)

所感

コンテナに関しては、社内であったAWSxSRE勉強会でやっとdockerとdocker-composeの違いであったり、dockerはプロセスである事を理解したばかりだったので、よい復習となりました。

現時点ではAWS上でdockerイメージを活用できていないので、そのうち今回学んだ内容を実践してみたいと思います。

#14. いまから始めるサーバレスアプリケーション

  • 登壇者(敬称略) : 清水 崇之(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : AWS Lambda や Amazon API Gateway を活用した基本的なサーバレスアプリケーションの構築についてお話しいただきました(なお、清水さんはAWS芸人らしいです)

概要

アーキテクチャについて

まずはアーキテクチャについての説明があった。

モノリシックアーキテクチャ

  • ひとつのなかに様々なアプリケーションが組み込まれている
  • ざまざまな開発者が関わっており、密結合なのでデリバリの速度が遅くなる
  • いわゆる密結合な状態

サービス指向アーキテクチャ(SOA)

下記の形で層を分けるアーキテクチャ

  • プレゼンテーション層(Frontend)
  • ビジネスロジック層
  • データ層(DB)

このSOAで重要なことは、インフラが分離していることである。
また、SOAでは特定の分野に特化したディベロッパーだけで集まることができるメリットもある。

マイクロサービスアーキテクチャ

  • SOAを更に細分化したもので、いわゆる疎結合な状態
  • これは組織のあり方に合わせたアーキテクチャを採用すると良く、組織のプロセスと合わせて採用するとよい。
  • Amazon自身もマイクロサービス化してきた。

実現していくための手段

AWSでは下記のマネージドサービスを利用して、アプリケーションを構築することが可能。

  • EC2
  • AutoScaling
  • ELB
  • EC2 Auto Recovery
  • Trusted Advisor
  • …etc

しかし、これらのサービスは相互に共有・依存するのである程度はサーバの面倒を見る必要がある。

サーバーとアプリケーション

上記に対して「サーバレス」とは、この依存するサーバについて何も考える事がなく、アプリケーションをビルドして実行できる状態であること。

これまで「オンプレミス → クラウド → サーバーレス」と下記のような工程でサーバーも進化してきており、よりモジュール化したアプリ開発にトレンドが移ってきている。

  1. データセンタ内の物理サーバ
  2. データセンタ内の仮想サーバ
  3. クラウド上の仮想サーバ
  4. サーバーレス

アプリケーションを動作させるにはサーバーが必要だが、 開発者としてはアプリケーションを動かすには、どのサーバーで動いているのかは重要ではなくなってきている。

サーバレスとは

改めてサーバレスの特徴をあげると、

  • サーバ管理が不要
  • 柔軟なスケーリング
  • アイドル時のリソース確保が不要
  • 組み込まれた可用性
    • これまではマルチAZなどで冗長性など考慮する必要があった

という特徴から「アプリケーション開発の本質」に集中する事が出来る(ちなみに本質じゃない事とは「インストール、設定、管理」)

AWS Lambdaとは

そこで出てくるのがAWS Lambda。
このLambdaがサーバレスの核となってくる。

特徴として、

  • アプリケーションをアップロードするだけでOK
  • AWSにはLambda以外にも堅牢なサービスが用意されているので、それぞれ組み合わせるとすばやくアプリケーション構築が可能

サーバレスがどのようにデリバリしていくのかを考える。

  1. 運用の複雑さを解消することにより、
  2. 開発者の生産性が向上
  3. 結果、マーケットに対するスピードがアップして
  4. より製品の改善にかける時間が増える
ユースケース

サーバレス利用の一般的なユースケースとして考えられるのは下記。

  1. Webアプリケーション
    • 静的なウェブサイトやアプリ
  2. バックエンド
    • アプリとサービス、モバイル、IoT
  3. ビッグデータ
    • データ分析
  4. Media & LogProcessing
  5. チャットボット
    • AlexaSkillなど

これらは、従来であれば「ELB & EC2 & RDS」等を組み合わせた構成・設計を考慮する必要があるが、サーバレスであればこれは不要となってくるので、下記のような構成で実現することが可能

  1. API Gateway & WAF
  2. CloudWatch & X-Ray Monitoring
  3. Cognito(認証)
  4. Lambda
  5. DynamoDB

コール回数や処理回数で課金されるのでスモールスタートが可能。

デザインパターン

様々なデザインパターンが存在する。

  • モバイルバックエンド
  • ワークフロー
  • 画像処理・テータ可能
  • AlexaSkill、ChatBot

考え方としては、

  • イベントとAPIを通じたコミュニケーショナル
  • ステートレスでエフェメラルな関数
  • データ、キャッシュおよびステートとロジックの分離

これらは「API GateWay」から「Lambda」経由で「DynamoDB」に…という形などで実現していく。

ただ、モノリシックなサービスからマイクロサービスにつなげていくと管理が煩雑になってきたりする。

これらの設計を簡略化することができるサービスとして「AWS SAM」というものがある。

AWS SAM

AWS SAMとは「Serverless Application Model」の略でAWS でサーバーレスアプリケーションを構築するために使用することができるOSS。

  • 関数、API、イベントソースとデータストア
  • サーバレスアプリケーションのデプロイと管理を簡略化
  • SAMのテンプレート(yaml, json)が存在しておりパッケージのデプロイが容易になる(つまりは、設計図のようなもの)

これらを活用しつつ、開発のワークフローを考えていかねばならなくなるので、そこはCodeサービスを利用してCI/CDを利用していく。

  • ソース管理 - Code Commit
  • ビルド処理 - Code Build
  • テスト - Third Party Tool
  • デプロイ - Code Deploy
  • モニタリング - X-Ray

これらを設定していくことは基本事項となる。

AWS CodeStar

上記の開発ワークフローを簡単かつ即座に作り上げる事ができる 「CodeStar」というサービスがある。

簡単に言えば上記の親玉のようなもので各種パイプラインを自動で構築してくれる。

  • 基本的に開発者はcodeをプッシュするだけでOK。
  • テンプレートを検索、選択するとサーバレスで実行される

CodeStar自体は「サーバレス」以外のものを用意されているので今回のケースに関しては「Lambda」で検索して探してポチポチすると、環境が用意できる。

用意された環境を編集して利用する事も可能で、 環境を編集する環境(IDE)も「Cloud9」「VSCode」等の中から選択する事が可能。

最初から、

  • サンプルコード
  • テストコード
  • SAMのテンプレートファイル
  • パイプライン

といった内容が全て設定されて入っているので、
開発者はコードをPushするだけで本番にリリースする事が出来る。

所感

サーバレスという名前だけ知っている状態でこのセッションを聞きましたが、今回これらを聞いて改めて「サーバレス」がどういった性質を持っていて、どのような考え方で利用すればよいか。

というところがクリアになりました。
早速、更に触って理解を深めたいと思います。

#15.「サービスメッシュは本当に必要なのか、何を解決するのか」

  • 登壇者(敬称略) : 原 康紘(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性についてお話しいただきました。

概要

サービスメッシュとは、独立稼働した複数のサービス(マイクロサービス)が1つのアプリケーションを構成して、各サービスが他のサービスと連携するために構成されるネットワークのアーキテクチャ。

  • 複雑に絡み合った送信経路の集合体を網の目(メッシュ、mesh)になぞらえたネーミングでそう読んでいる。
  • マイクロサービスを成功するためには、このサービスメッシュ を適切に運用管理する必要がある。

クラウドネイティブコンピューティングが加速してマイクロサービス化がすすむ中、 これまでの対応ではさまざまな問題を孕むようになってきた。

サービス間通信の信頼性を高める防御的実装

  • 呼び出し先サービスの位置は一定ではない
    • 「サービスディスカバリ」で対応
  • 一時的な呼び出しの失敗
    • 「リトライ」で対応
  • 継続した呼び出しの失敗
    • 「サーキットブレイカー」で対応
  • 呼び出しもとサービスのパフォーマンス悪化
    • 「タイムアウト」で対応
  • 呼び出し元サービス
    • 「スロットリング」で対応

サービス間通信の可観測性

ユーザから見ると「マイクロサービス」は「ひとつのサービス」でしかない

  • しかし外形的には「システム」の失敗。
  • 「失敗はいつ、どこで、なぜ起きたのか」これが詳細にわかる必要がある
必要なもの

そのために各マイクロサービスから必要となる情報として、

  • ログ
  • メトリクス
  • トレース情報出力

これらの情報が必要になってくるが、

  • 各サービスの既存出力フォーマットが不揃いだとコンテキストが見えない
  • システム全体の観測は不向き

といった問題が顕在化してしまうため「サービスのフォーマット」をあわせる必要が出てくる。

そもそも全てを実装しきることは可能なのかと考えると、

  • 各サービスの個別実装
  • 複数の言語・フレームワーク
  • 実装担当者と品質担保方法
  • 統一フォーマットの変更

これらに一貫性のある実現方法が必要となってくる。

一貫性のある実現方法

これらを実現するために、「サービス間通信の信頼性」や「可観測性実装」をどうすればよいかという話になる。

共通ライブラリという解決方法ではどうか

下記のような問題が発生する。

アプリケーション側

「アプリケーションの改修が必要だ!」

  1. 「共通ライブラリでパフォーマンスが悪化しました!」
  2. 「YY言語 v2対応はまだですか?」
  3. 「XX言語用のライブラリがないです」

共通ライブラリ側

  • 「マイクロサービスがライブラリを入れてないらしい」
  • 「フォーマットを変更したいけど、全ライブラリの改修はしたくないな」
  • 「最新ライブラリに移行してくれないチームがいます…」
  • 「この言語、書いたことないんですが…」 

一貫した実装である「共通ライブラリ」が密結合を生む結果となってしまう。

解決策としての「サービスメッシュ」

サービスメッシュは「プロキシへのオフロード」というアイデアで解決する。

アプリケーションがプロキシを通して送信、そちらで計測。
プロキシ側で「リトライ」などの処理を行い、観測した方法でメトリクスやログの取得を行う。

Envoy proxyプロキシがデファクトスタンダート。

  • OSSでコミュニティサポートと多くのインテグレーション
  • 多くの本番環境利用実績がある

設定としてはYamlを編集し、トラフィックはこっちに流すとか、このサービスにはここという設定を行っていく。

ただし、これも課題として「このプロキシは誰が管理しているのか?」というものが発生する。

  • 「中央の設定を行っているチームでは?」
  • 「アプリはアプリを開発しているチームでは?」

マイクロサービスのチームと、中央で管理しているチームのハレーションが発生する。

AWS AppMashによる解決

AWS App Mashを利用する事で上記で上げた問題を解決する事が可能。

  • マイクロサービスは好きなタイミングでアプリをデプロイ
  • 中央はAppMashにコールするだけ

これによって「再デプロイが不要」になる。

AWS App MashとはサービスメッシュのControlBrainで、メッシュ全体構造の定義が出来る。

  • アプリケーションレベルのネットワーク
  • クラスタやサービスにまたがるメッシュの構築
    • コンテナだけのものではなく「ECS / Fargate / EKS / EC2 … etc」
  • マネージドブレーン
  • トラフィック管理
    • トラフィックコントロール
    • ルーティング
    • ロギング
    • メトリクス
    • 分散トレーシング

東京リージョンで使えるし、利用するのに料金もかからない。

App MashのパブリックロードマップもGithubに公開しているので、フィードバックも募集している。

まとめ

「サービスメッシュは本当に必要なのか?」という事を考えてほしい。 置き換えると「あなたのシステムにとって、サービスメッシュは必要なのか?」という事。

サービスメッシュとは

  • サービス間通信の信頼性、可観測性実装を確保する一貫性ある手段のひとつ
  • 「AWS App Mesh」という選択肢があること
課題に対する必要性を検討してほしい

そもそもサービスメッシュは必要か?

  • X-rayの分散トレーシングだけでいけない?
  • ALBでのトラフィックコントロールだけでは足りない?
  • OSSライブラリの利用で十分な低コストなケースじゃない?

動的なサービスメッシュが必要?

  • Envoyに静的設定ファイルを利用するだけで補えないのか?

これらを考えてからApp Mashを検討すると良い。

所感

これまで「サービスメッシュ」という名前しか知らなかったので、このセッションを聞いた事で「どのようなモノで、どのように利用されるものなのか」という事がわかりました。(とはいえ、割とエンフープライズ規模の開発じゃないと利用しそうにないなぁという印象も受けた)

#16.「サーバレスアプリケーションのためのセキュリティアーキテクチャ」

  • 登壇者(敬称略) : 桐山 隼人(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : サーバーレスコンピューティング環境において考えておくべきセキュリティの要点と、開発者がAWS上でセキュアなアプリケーションを実現するアーキテクチャについてお話しいただきました。

概要

このセッションでは「構成要素を知ること」「セキュアに設計すること」について説明がありました。

サーバレスアプリケーションの構成要素とは

復習となりますが、サーバーレスアプリーションに取り上げられる特徴として下記のようなものが存在する。

  • サーバー管理が不要
  • 柔軟なスケーリング
  • アイドル時のリソース確保が不要
  • 高可用性

「オンプレミス」「VPC(クラウド)」「サーバーレス」ごとに、開発者側で行う必要のある役割が減る。

オンプレの場合は下記のすべてを考える必要がある。

  1. アプリケーション作成
  2. スケールアウト設計
  3. 提携運用設計
  4. ミドルウェアパッチ
  5. ミドルウェア導入
  6. OSパッチ
  7. OS購入
  8. HWメンテナンス
  9. ラッキング
  10. 電源ネットワーク

次にVPCの場合は、

  1. アプリケーション作成
  2. スケールアウト設計
  3. 提携運用設計
  4. ミドルウェアパッチ
  5. ミドルウェア導入
  6. OSパッチ

サーバーレスの場合には、

  1. アプリケーション作成

その他の所はAWSに任せる事ができるので開発者側で考える事 とてもシンプルになる。

サーバレスなアプリケーションモデル

イベントソース

  1. S3にオブジェクトが作られる
  2. Kinesisにストリームデータが保存される
  3. HTTPSによるリクエスト
  4. etc

ファンクション

  • 各言語での処理

サービス呼び出し

  • 呼び出し例としては「データベース読み書き」「ファイル操作」「通知」など

最も基本的なAWSのサーバレスアーキテクチャは下記のような形となる。

  1. クライアントからアクション
  2. API Gatewayにイベントが送信される
  3. AWS Lambdaでファンクションが実行される
  4. Amazon DynamoDBにデータを取りに行く

このような形でサーバを気にすることのないアプリケーション開発・実装が可能となる。

構成要素まとめ

「AWS Lambda」のメリット

  1. インフラ管理が不要
    • ビジネスロジックにフォーカスすることができる
  2. 高いコスト効率
    • 使った分だけ100ms単位で課金される
  3. 自分のコードを実行できる
    • 標準的な言語のコードを実行可能

「API Gateway」のメリット

サーバーレスの構成に(ほぼ)合わせて登場する「API Gateway」とは、どんな規模であっても簡単にAPIの「作成、配布、保守、監視、保護」ができるマネージドサービス。

  1. APIの定義とホスティング
    • 統一化されたAPIの作成と管理
  2. ネットワークトラフィック管理
    • バックエンド保護のためのDDoS対策やスロットリング
  3. AWSの認証の仕組みを活用
    • 認証認可の仕組みが利用できるので、クラウド上のリソースへのアクセス認証が可能

上記のアーキテクチャを応用すると様々なユースケースに対応できる。
(ここらへんは前のセッション内容に記載)

主なユースケース例

モバイルバックエンド

  1. ブラウザからアクション実行
  2. 静的コンテンツはAmazon CloudFront => S3
  3. 動的コンテンツは API Gateway => Lambda => DynamoDB

Data Processing

  1. IoT機器からアクション実行
  2. Amazon Kinesisがストリームで受け止め、
  3. Lambdaファンクションを実行
  4. DynamoDBにデータを取りに行く

どのようにサーバレスアプリケーションをセキュアに設計するのか?

本題。

基本的には「Well-Architected Framework」を確認する事になる!!
…だとあまりにも乱暴すぎるので、もうちょっと丁寧に説明すると、

「Well-Architected Framework Serverless Application Lens」というベストプラクティスを確認する。

  • 「Lens」は小さく分けた特有毎に集めたホワイトペーパーであり、ベストプラクティス集である。

「Serverless Application Lens」の内容を掘り下げていく。

セキュリティの柱

これは、ビジネスにおける価値を生み出しながらリストアセスメントと防御戦略により「情報、システム、資産」を守る能力

  • IDとアクセス管理
  • 発見的統制
  • インフラストラクチャー保護
  • データ保護
  • インシデントレスポンス

「IDとアクセス管理」の考慮事項

下記の問いに対して「根拠ある理由があり、問題はない」と言える必要がある。

  1. APIアクセスの認証認可はどのようにしているか?
  2. LambdaファンクションがアクセスできるAWSサービスをどのように保護しているか?

上記の対処として考えることは、

  • ユーザ管理とアイデンティティ
  • IAMの活用
  • 既存IdPの活用
  • 最小限の原則

といった所が例としてあがる。

Amazon Cognite User Pools

「Amazon Cognite User Pools」というサービスがある。 これは、ウェブ/モバイルアプリケーションの認証、許可、ユーザー管理をサポートする。

メリット

  1. ユーザ管理を簡単に
    • サインアップ/サインイン機能をアプリに簡単に追加
  2. マネージド型ユーザディレクトリ
    • 数億まユーザまでScaleするユーザディレクトリを作成・管理するフルマネージドなサービス
  3. 拡張されたセキュリティ機能
    • 電話番号やemailアドレスの検証と多要素認証を提供
    • 普段と異なるトラフィックがあった場合に…という対応ができる

API Gateway アクセス認可の方法

API Gatewayのアクセス認可に関しても下記の方法がある。

  • Cognite User Pools Authorizer
  • AWS IAM Authorization
  • Lambda Authorizers
発見的統制の考慮事項

これは「サーバレスアプリのログをどのように分析しているか」という観点。 考慮したほうが良いものとしては下記。

  1. API Gatewayアクセスログの設定を有効にする
    • カスタムアクセスログの有効化が大事。
      • 全てを残せば良いというわけではない。
      • 個人情報が入ってくる事もあるので、フィールドを見て慎重に判断する
  2. AWS X-Rayを使ったトラブルシューティング
    • サービス間イベント繊維を可視化する
    • Lambdaファンクションから他のサービスに対する呼び出しと時間をトレース。消えたイベントやスロットル状態の確認、診断ができる
インフラストラクチャー保護の考慮事項

下記について検討すること。

  • Lambda FunctionのVPCアクセス
  • Firewallによるネットワーク境界保護
    • AWS WAF(RateLimit / 正規表現などWAPに基づいたルール)
    • DynamoDBの場合は、セキュリティグループに基づいた保護
データ保護の考慮事項

データ保護に関しては、下記について問われた際に答えられるようにする。

  • サーバレスアプリ内の機微情報をどのように保護しているか
  • どのように入力値をチェックしているか

これに対する考え方としては、

  • 通信データの暗号化
  • クライアントサイドの暗号化
  • ログに機微情報が含まれる可能性の考慮

また、保護すべきデータの外部化を行うため下記を検討する。

  • AWS SSM Parameter Store
  • AWS Secret Manager

AWS Secret Managerとは

EC2インスタンスにOSとアプリを載せたケースなどに、コードの中に書きたくない管理者クレデンシャルを安全かつ必要な時だけ参照したい場合、SecretManagerに格納することで、アプリのコードではSecretManagerを呼び出すだけで、DB認証情報を返却するようにすることが可能。これによりDBの鍵がローテーションで変更されても問題ない。

インシデントレスポンスの考慮事項

インシデントレスポンスに関して考える必要があることは下記。

  1. 侵入テスト
    • テストが許可されるAWSリソース
  2. 申請が必要なイベント
    • セキュリティシミュレーション
    • レッドチームテスト
    • ブルーチームテスト
    • 労災

AWS WAF セキュリティオートメーションというものを使えば、自動的に対応する事も可能。

まとめ

well architected frameworkを活用することで下記が判明する。

  • IDとアクセス管理を行う方法
  • 発見的統制によってインフラ管理を行う手法
  • そしてインフラで保護する方法
  • データ保護の方法

所感

AWSの学習をし始めてから「Well Architected framework」という単語を毎日見ているような気がします。 このセッションではこの「Serverless Application Lens」という所に絞った内容で、細かくどこで何を考えるべきなのか、また何を行うべきなのかについて説明していただきました。 現時点ではまだあまりサーバレスアプリケーションを開発する機会がそこまでないのでアレですが、触る時のこちらで記録した内容を確認しつつ、Well Architected framework Serverless Application Lensを確認してみたいと思います。

#17.「めざせ!サーバレスプロフェッショナル」

  • 登壇者(敬称略) : 清水 崇之(AWS Japan - 技術統括本部 ソリューションアーキテクト)
  • 備考 : サーバレスアプリケーションを本格的に活用するうえで知っておきたい、フレームワーク、CI/CDパイプライン、チューニング、運用と監視について解説いただきました。

概要

サーバレスとは 開発テスト/Framework 複数環境、CICD 監視、モニタリング DesignPattern

サーバーレスとは

  • これは省略(前のセッションで聞いた)

開発テストとフレームワークについて

開発する際のIDE(綜合開発環境)はどうすればよいか?

  • AWSの場合はCloud9があるのでそれを使うことも可能
  • あと「AWS Preview KIT」というものもあるので、それを活用すれば普段使い慣れたIDEで開発する事もできるらしい。
    • 私の場合は「VSCode(Preview)」

小さなパーツをどのように管理するのが良いか?

AWS SAM(Serverless Application Model)で管理するのが良いとのこと。 - SAMに関しては前のセッションで聞いた内容なので割愛

[こちら]でAWSがツール、サンプル、ライブラリなどを開発&公開しているので参考にすると吉。 - 「Express.jsのサンプルを動かす」というようにサンプルもある。

また、AWS SAM CLIというサーバレスアプリのためのローカルテストツールがあり、ローカルマシンでレスポンスやログの確認ができるとのこと。 - 実態はLambdaの実行環境をエミュレートしたDockerイメージで、タイムアウト、メモリーリミットなどがある - ちなみに昔は「SAM Local」という名前だったらしい

使い方

`sam init —runtime nodejs8.10

とすると、サンプルコードやRuntimeの設定がされたものが用意されるので、 あとはよしなに利用していけば、開発、テストがスムーズに進める事が可能。

これでApplicationが出来たら、複数環境、CI/CDを用意していく必要がある。

複数環境とCI/CD

開発・テスト・実行には複数環境が必要となる。

下記を考える。

  1. アカウント戦略 : AWSアカウント分ける
  2. 環境変数 : それぞれの環境の固有の変数を用意
  3. SAM : インフラストラクチャーのコードとして利用
  4. CI/CD: Applicationのテストとデプロイを自動化する
アカウント戦略
  1. 同じアカウントでスタックを分ける
    • 特徴 : 小規模チームや個人に向いている
    • メリット
      • リソース管理が簡単
      • 管理や監視ツールを見やすい
    • デメリット
      • 許可やアクセスの分離が難しい
  2. アカウントを分ける
    • 特徴 : 大規模チームや企業に向いている
    • メリット
      • 許可やアクセスを確実に分離できる
      • アカウントごとのリソース制限を管理
    • デメリット
      • 複数のアカウントとそれらの間のコントロールを管理するのが難しい

この場合はAWS Organizationとかも考慮するとよさげ。

環境変数 : Lambda
  • 関数に動的にわたす事ができるキーと値のペア
  • Nodeのenvや、Pythonのenv
  • KMSでKMS経由で暗号化 ...etc

バージョニング・エイリアス - エイリアスはLambda関数の特定のバージョンに対するポインタ

API Gateway : ステージ - 環境変数のように利用できる - $ contextオブジェクトで利用できる

CI/CD

SAMを活用した場合、インフラストラクチャーのコードとして活用できるので、Codeサービスと組み合わせることが可能。

登場人物は下記。

  1. CodeCommit
  2. CodePipeline
  3. S3
  4. CloudFormation & SAM

これらから、LambdaとAPIGatewayにCI/CDを行う。
ちなみに1から4までの準備を簡単にしたい場合、CodeStarを利用すると便利らしい。

おまけ

段階的にデプロイメントが可能

  • デプロイメントパフォーマンスを設定する事で、数%ずつ、新しいバージョンのLambdaに…みたいな事が可能

アラーム、フック - Lambda関数が成功・失敗でAllowTraffic可能

API GatewayのCanaryリリースという機能もある

  • 新しいステージのデプロイに進むTrafficの割合を設定して、開発ステージの設定や変数をテストできる。
  • 問題がなければ、本番に昇格する事ができる
  • A/Bテストにも利用する事ができる。

再利用する場合

  • SAM / CloudFormationを活用可能
  • これは、Serverless Application Repository経由で再利用する
    • AWS CodePilpeline SAR Auto-Publishで自動化するなど

監視、モニタリング

Lambdaも統合されているので下記を利用可能。 - CloudWatchメトリックス - デフォルトメトリックス - カスタムメトリックス - CloudWatchログ

また、Applicationモニタリングには、AWS X-Rayも使える。

  • リクエスト実行状況の確認、問題の検出
  • パフォーマンスの改善から、さまざまなアプリの解析

所感

SAMの詳細は割愛…と記載しながら、まだSAMを活用したことがない状態なので、CloudFormation => SAM、そしてCodePipeline周りの整備を触ってみたのち、CodeStarを触って「すげー」という体験をしてみようと思いました。

3日目の感想

3日目は個人的にも前のめりになるレベルで興味があった「コンテナやサーバーレス」関連のセッションを中心に聞いてましたが、やはり人気なのか参加される方の待機列が、通路を塞ぐのでこれ以上は並びきれないレベルにまで到達していたのが印象的でした。 ひとまず、直近にでもLambdaとAPI Gatewayを利用した簡単なアプリを作成してみたいと思います。

他の日程のレポート

1日目のレポートはこちら

blog.kglabo.com

2日目のレポートはこちら

blog.kglabo.com

3日目のレポートはこちら

blog.kglabo.com