fuzzy study

仕事・趣味で勉強したことのメモ

AWS Summit Tokyo 2019 3日目午後に参加したメモ（コンテナ・サーバレス）

AWS serverless コンテナ

3日目の午後だけAWSSummitに参加してきた。
たまたまなんだけど、コンテナとサーバレス関連のセッションを立て続けに聞いてきて、概要把握に役立ったので、レポートしておく。

12:00-12:40 【初級】AWS コンテナサービス入門

コンテナの復習

コンテナの特徴

  • アプリが依存するものをひとまとめにして可搬性を持たせる仕組み
  • 仮想マシンと違い、実体は（環境隔離した）プロセスなので起動が早い

dockerの責務は一台のマシン上でのコンテナライフサイクル管理なので、複数マシンへのデプロイなどは範疇外。 そこで、コンテナオーケストレーションの出番。

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

ECSを使ったコンテナオーケストレーション

  • できること
    • EC2クラスタ作成
    • デプロイ、AZ指定、LB接続などなど
  • リリース当時はマネージドサービスとしてコンテナオーケストレーションできるサービスはなかった
  • windowsコンテナもサポート

k8s(EKS)を使ったコンテナオーケストレーション

  • k8sの51%がAWSで動いているという
  • kubectlを使って管理できる
  • OSSに改変を加えずそのまま使っているので、移行容易性についてCNCF Certifiedを受けている

ECR

  • コンテナイメージのレジストリ
  • ローカルからも使える

Fargate

  • ECSを使っても、実行環境としてのEC2の管理が必要
    • ECS Agentの導入や、パッチあて、スケール管理などなど
  • Fargateは、コンテナ実行環境もマネージドサービスとして提供する

なお、Fargateの課金体系は

Amazon ECS の場合、AWS Fargate の料金は、コンテナイメージのダウンロード (docker pull) を開始した時点から Amazon ECS タスクが終了するまでに使用された vCPU およびメモリリソースに基づいて計算され、最も近い秒数に切り上げられます。1 分の最低料金が適用されます。

となっている。

その他、コンテナにまつわる話題

CloudMap

  • サービスディスカバリのためのマネージドサービス
    • マイクロサービスにおけるDNS的なもの
    • Lambdaなど、arnで管理されるものの名前解決も行う

AppMesh

  • APレベルのネットワーク
  • サービスメッシュ

CloudwatchのContainer Insights

  • コンテナ専用モニタリングサービス

設定値管理

  • AWS Systems ManagerのParameterStoreを使って、DB接続用パスワード等の秘匿情報を渡すことが簡単にできる

所感

AWSでコンテナを使うためにどのサービスを使えばよいのか俯瞰して理解できた。
Fargateについては、コンテナが動いている間だけの課金ということでEC2で動かすよりも少しは節約できそう。
GCPのCloudRunとFargateの違いを考えていたのだけど、FargateにECRのイメージをイベントドリブンでpull→runができたら同等になるイメージなのかな？

13:00-13:40 Kubernetes on AWS (Amazon EKS実践入門)

AWSでk8sつかってみたいけどまだ踏み切れてない人向けのセッション。

コンテナ復習

  • ユースケース
    • マイクロサービス
    • ジョブ実行
    • CI/CDの実行
    • 機械学習
  • 実行時（RUN）の課題
    • ホストが多くなったときの管理

kubernetes(k8s)

CNCFのgraduatedプロジェクト

人気の理由

  • ユーザ数、コミュニティ
  • RunsAnywhereの思想（クラウドでもオンプレでも）
  • 拡張可能なAPIとエコシステム

機能

  • ノードにコンテナを自動配置
  • セルフヒーリング
  • オートスケール
  • オートアップデート
  • ストレージマウント
  • 通信相手の名前解決
  • ・・・などなど

VMwareをやっていた時代で止まっていた身としては、vCenterServerを思い出しつつ、よりアプリ目線での管理項目が増えている印象。コンテナってアプリのプロセスそのものの存在なので、当然っちゃ当然か。

構成要素

  • マスターサーバ群＝コントロールプレーン
    • 動作のために多くのプロセスが存在する
    • k8sの動作の根幹機能のため、冗長構成が必要
    • つまり構築も管理も大変！
  • ノード群＝データプレーン
    • Podを配置する先のリソース
  • Pod
    • デプロイの最小単位
    • 1つ以上のコンテナで構成される
    • Pod内のコンテナはIPアドレスやストレージ等を共有する
  • Service
    • Podを名前解決により発見する
      • 例） myapp → namespace: production
    • LB（L3/L4）機能を提供
  • Deployment
    • Podを維持、コントロールするレプリカセットの管理
    • ローリングアップデート、世代管理

設定・管理方法

yaml（マニフェスト）で宣言型の設定を行う。
コントロールプレーンのAPI Serverに適用すると、内部で設定どおりの構成になるよう、よしなに動いてくれる。

k8sについてはもっと中身を詳しく学んでおいたほうがよさそう・・・

k8sとAWS

通常はコントロールプレーンもデータプレーンもEC2で構築するが、特にコントロールプレーンはアップデートとか冗長化とか、構築も管理も大変。なのでマネージドサービス。

EKS

k8sのコントロールプレンをマネージドサービスで提供したサービス。
コントロールプレーンはAWS側のVPCに構築され、ユーザからはkubectlで操作する形になる。

使うメリット

  • コントロールプレーンの運用から解放
  • k8s運用支援機能
    • バージョンアップ、コントロールプレーンのログ集約、などなど
  • AWSのサービスとスムーズな連携
  • データプレーンの選択性

使い方

  • IAM割り当て
  • eksctl, kubectlインストール
  • yaml準備
  • eksctlで設定適用
  • クラスタがたつ
  • kubectlで操作

デモ

Sock shopというデモ用のアプリで動作のデモ。
実はk8sマニフェストでAWSリソースを管理できちゃうので、想像以上に機能性や自由度が高い。

ユースケースとAWS連携

HTTP[S]対応LBを使いたい

  1. IngressによるLB機能を使う
  2. ALB Ingress Controllerを使う
    • ALBを自動デプロイできる機能

ログ集約

  1. FluentdのDaemonsetでやる
  2. [New] Cloudwatch Container Insightsを使う
    • コンテナログ、メトリクスを集約
    • 数個のマニフェストを適用するだけでセットアップ
    • コントロールプレーンのログも見れる

オートスケール

  • Podレベル
    • k8s機能の範囲でできる
  • ノードレベル
    • AWS AutoScalingと連携させる
    • Podステータスpendingを検知してノードのスケーリングを実行

デプロイ効率化

  • CodeCommit/CodeBuild/CodePipelineでCI/CD
  • buildトリガーでLambdaでマニフェスト？のコンテナイメージのタグのバージョンを書き換えるらしい。ここはよく理解できなかった。

堅牢なデータストアを使いたい

  • マネージド系DBの使用がおススメ

ラーニングパス

より詳しく学ぶには、BlackBeltやEKS Workshopを活用ください。

所感

k8sの役割とEKSを使うメリットについて理解できた。
k8sコントロールプレーンの構成を見ていると、マネージドサービスを使う利点は考えるまでもなく大きい気がする。
これだけコンテナ環境をお手軽に使えるようになってくると、いよいよ爆発的に流行りそう。

14:00-14:40 サービスメッシュは本当に必要なのか、何を解決するのか

サービスメッシュってなに？

Monolithなアプリとは

  • Does Everything
  • 課題
    • 関係者調整のオーバーヘッド
    • 変更による影響範囲の広さ
    • モジュール構造維持の難しさ
    • 非効率なスケーリング
    • テスト・ビルドに要する時間の長さ

マイクロサービス

  • モノリシックなアプリの課題を解決するために考案された
  • Does one thing
  • Polyglot(-able) => 複数の言語を使って実装できる

monolithの考察

  • AWS X-Ray を使うと、モノリシックなアプリでもサービス間通信の状況を監視・可視化できる
    • 分散アプリケーションの分析調査のための分散トレーシングサービス
    • サービス間通信の可視化など
    • 呼び出し順に従ってAPIにかかった時間を可視化
    • プログラム側にログ出力を書く
    • （GCPのStackDriver Tracingと同じ感じ？）

マイクロサービス

  • 通信状況を可視化するとヤバい複雑
  • 課題
    • サービスの適切な分割
      • 正解がないので難しい
    • テストの難しさ
    • 影響範囲を自サービス内に収める難しさ
      • APIインタフェースだけは絶対に崩せない
    • サービス間通信の信頼性(Reliability)・可観測性(Observability)

Reliability確保のための策

ネットワーク状況・対向サービス状況による失敗がありうる。そこで、防御的実装の必要性が生じる。
防御的実装とは以下のような事象に対応する実装のこと。

  • 呼び出し先サービスの位置が変わる → サービスディスカバリ
  • 一時的呼び出しの失敗 → リトライ
  • 継続した呼び出しの失敗 → サーキットブレーカー
  • 呼び出し先パフォーマンス悪化 → タイムアウト
  • 呼び出し元システムの不具合 → スロットリング

Observability確保のための策

エラーがどこでなぜ起きたのか分析できる必要がある。

  • ログ・メトリクス・トレース情報出力
    • これらが各サービスでちゃんとやられてる？？
    • 出力フォーマットは整っている？？
  • たとえ個別実装できていたとしても、システム全体の観測に不向きな実装となりうるため、一貫性のある実現方法が必要。

一貫性のある防御的実装の実現策

  • ありがちな「共通ライブラリ」は密結合になるため、ことマイクロサービス開発においては不向き
    • マイクロサービスの開発体制においては、疎結合な実装、自律的チーム関係の維持が成功の秘訣
  • プロキシへのオフロード
    • 共通的実装が必要なレイヤを下層におき、処理をオフロードする
    • これをサービスメッシュという！
    • （共通ライブラリ機能を一つの（分散型）マイクロサービスとして提供するイメージ？）

サービスメッシュ

Envoy Proxy

  • 特徴
    • CNCFのgraduatedプロジェクト
    • サービスメッシュのデファクト実装
    • yamlを書いて適用するスタイル
  • 設定ファイルがあるとやっぱり密結合になるのでは？
    • アプリと一緒にプロキシもデプロイしないといけないんですか？ →AppMeshが解決！

AppMesh

  • AppMeshの特徴
    • サービスメッシュのコントロールプレーンをマネージドサービスで提供
    • メッシュ全体の構造定義を持つ
    • 各プロキシの設定を動的に配信する
    • クラスタやサービスにまたがるメッシュの構築
      • EC2やFargateも含められる
    • 利用自体には料金不要
    • 東京リージョンで利用可
    • Githubにパブリックロードマップあり
  • 機能詳細

あなたのシステムにとってサービスメッシュは本当に必要なのか？

システム規模や要件に応じて、どこまで導入すべきか検討の余地がある。

  • XRayやALBで十分なケース
  • Envoyの利用で十分なケース
  • 動的なサービスメッシュがいるなら、AppMesh

所感

サービスメッシュの正体がいまいちつかめていなかったので、ぼんやりとでもイメージできるようになったので大変有用なセッションだった。
マイクロサービスにおいてはサービス間通信がアプリケーションの関心ごととなり、かつ規模が大きいと複雑化するので、そのレイヤにおいて共通的な非機能面をカバーするプロダクトが必要で、それがサービスメッシュだ、とざっくり理解した。
（2019/6/21追記）それがサービスプロキシで、サービスメッシュはそれらを統合管理するレイヤ、っぽい。Envoyがサービスプロキシ、AWS AppMeshやIstioがサービスメッシュ。（追記ここまで）
おそらくこれまでも大規模システム開発の現場ではこういったAPの共通的非機能レイヤを受け持つ部隊はあったと思うが、市場全体でみるとレアケースだったのか、あるいはアーキテクチャとして定型化されていなかったかで共通的な名称はなかったが、マイクロサービスという定型化されたものに乗っかって名前が与えられた、という感がある。
セッションの話の流れも、従来のモノリシックなシステムからマイクロサービスへの変遷、それによる課題の移り変わり、と順を追って進み、サービスメッシュが解決する課題がマイクロサービスの課題の何にあたるのかがイメージしやすかった。

たぶん今回参加して一番ためになったセッション。

15:00-15:40 サーバレスアプリケーションのためのセキュリティアーキテクチャ

サーバレスアプリの構成要素

  • 基本形：API Gateway → Lambda → DynamoDB
  • ユースケース
    • Webアプリ
    • Backend
    • データ分析
    • チャットボット
    • Alexa
    • 自律的IT
  • サーバレスを構成するサービス群（一部）
    • 認証 - Cognito
    • エッジ - Cloudfront
    • メッセージング・ストリーミング - SNS, Kinesis
    • データ - Dynamo, S3, Elasticsearch service
    • コンピュート - API Gateway, Lambda, StepFunctions
    • 監視とデプロイ - CloudFlont, X-Ray

サーバレスアプリをセキュアに設計する

  • Well-Architected Framework - Serverless Application Lens
  • セキュリティの柱
    • IDとアクセス管理
    • 発見的統制
    • インフラ保護
    • データ保護
    • インシデントレスポンス

IDとアクセス管理

APIアクセスの認証認可をどうするか？
LambdaファンクションがアクセスできるAWSサービスをどう保護するか？

  • Cognito User Pools
    • マネージドユーザーディレクトリ
    • 多要素認証のサポート等、拡張されたセキュリティ機能を提供
  • 3通りの方法
    • User Pools Autorizer（一般ユーザ向け）
    • IAM Authorization（AWSリソースへの直接アクセスする管理ユーザ向け）
      • UserPoolに認証リクエスト、JWTトークンを返す
      • IdentityPoolsにAWSクレデンシャルリクエスト、一次AWSクレデンシャルを返す（STS？）
      • APIGatesayリソースアクセス
      • APIGatesayがIAMポリシー確認
      • IAMポリシーにて、APIリソースごとのアクセス可否を設定可能
    • Lambda Authorizer（AWSリソースへの直接アクセスする管理ユーザ向け）
      • IdPに認証リクエスト、カスタムIdPトークン
      • APIGatewayへリクエスト
      • Lambdaがトークン検証し、IAMポリシー生成
      • あとはIAM Authorizationと同じ
  • 発見的統制
    • APIGatewayアクセスログの設定
    • ログトレース→カスタムアクセスログの有効化
      • 機密性の高い情報をログに残さないように気を付ける
    • X-Ray
      • Lambdaから他のサービスに対する呼び出しと時間をトレース
  • インフラ保護
    • LambdaからVPC内のアクセスについてネットワーク境界をどう保護しているか
    • APIGateway　＋　WAF（RateLimit、正規表現など）
    • VPC内ならセキュリティグループ
  • データ保護
    • 機密性の高い情報をどう保護するか
    • 入力値バリデーションの方法
    • SystemManager Parameter Store
      • 設定データの安全なストレージ
    • Secrets Manager
      • DB管理者の鍵などを保管
      • ローテーションも自動化
    • 侵入テスト
      • 事前申請なくできるようになった
        • Lambda、APIGatewayとかも
      • WAFセキュリティオートメーション
        • WAFフルログ送信→Firehose→S3→Athenaで分析→WAFルール更新

所感

サーバレスアプリケーションにおける認証認可の方式について細かい話を聞けるかと思っていたけど、もっと広く浅い話だった。
でもこういった切り口の話はAWS公式ドキュメントでもまとまっている資料があまりない印象なので、サーバレスの組み方として大変参考になった。
そもそもAWSにおけるサーバレスの構成要素となるサービスについてちゃんと把握していなかったんだなあと実感。「Well-Architected Framework - Serverless Application Lens」は英語だから何となく敬遠していたけど、目を通したほうがいいのかも。。

16:00-16:40 目指せサーバーレスプロフェッショナル

AWS芸人な方のセッション。

開発、テスト、フレームワーク

開発環境

  • Cloud9
    • 東京リージョンも使用可となった
    • 各種エディタのプラグインがある
  • AWSSAM
    • サーバレスアプリを表現する標準モデル
    • ライフサイクル管理
    • CloudFormationの拡張
    • 使い方
      • SAMテンプレート（yaml）
      • packageコマンド
        • CloudFormationテンプレートに変換され、S3にアップロード
      • deploy
        • CloudFormationが動きリソース作成
    • AWS Labに多数サンプルあり
  • AWS SAM CLI (旧 SAM local)
    • ローカルテストツール
    • レスポンスやログ確認が可能
    • Lambda実行環境をシミュレートしたDockerイメージを提供
      • サンプルアプリ作成
        • sam init --runtime nodejs8.10
      • イベント作成
        • sam local generate-event s3 --bucket hogeBucket --key hogekey > s2event.json
      • Lambda呼び出し
        • sam local invoke hogeFunction -e s3event.json
      • APIローカル実行
        • sam local api
      • などなど

複数環境、CI/CD

複数環境

  • アカウント戦略
    • 分けることのメリデメを考慮
  • Lambda
    • 環境変数
      • pythonのos.environなど標準的なAPIで利用可能
      • KMS経由で暗号化可能
      • ステージごとに環境を作るのに利用すると便利
    • バージョニング・エイリアス
  • APIGateway
  • SAMテンプレートと環境変数を使って複数環境を構築

CI/CD

  • Codeシリーズ
  • CodeStarを使うと代表的パイプラインをテンプレートで提供してくれる
  • 段階的デプロイメント
    • DeploymentPreferenceにカナリヤ・リニアなどのパラメータを指定する
    • アラームとフックを指定可能
    • APIGatewayもカナリヤリリース可能
      • A/Bテストとかにも使える

再利用

  • SAM/CloudFormationを使う
  • Serverless App Repositoryを使う
    • CodePipeline SAR Auto-Publishで自動化できる

監視、モニタリング

  • 基本Cloudwatchに統合されている
  • X-Ray使う
    • トレース
    • サービスマップ
      • 各サービスの呼び出し結果を色で分類して割合を円グラフにして可視化
      • 平均レイテンシ、トレース数、など

デザインパターン

所感

盛りだくさんのセッションだった。
サーバレスはどうやってテストやCI/CDすればよいのかイメージがついていなかったけど、SAMのようなツールを使ったり、各サービスの環境変数にあたる機能を駆使すればローカル開発・テスト含めて実現できることがわかった。
以前書いた記事で抱いた課題感への答えになりそう。 しかしそれでも、こういった開発周辺ツールも含めてサーバレス環境はベンダロックイン感がどうしてもぬぐえない。
別セッションだったかもしれないけど、「サーバレス」-「コンテナ」-「仮想マシン」という3種類の環境を目的や背景に応じて使い分けることが重要、という話だったので、今後もそれぞれのメリデメ把握を続けるのが大事だと感じた。
今のところコンテナが、アジリティもポータビリティもあって万能のように感じてしまうけど。。