[セッション] コンテナとサーバレスを使用してモダンアプリケーション開発を加速させる con213-L #reinvent

コンテナとサーバレスを使用してイノベーションを加速させる方法をベストプラクティス, 新機能を元に学んでいきます.
すでに動画も出ていますので, 合わせてご確認ください.

• タイトル: Using Containers And Serverlesss To Accerate Modern Applicaation Development
• セッションID: CON213-L
• スピーカー: Deepak Singh 様, David Richardson 様

The Value of Building Blocks

• 一般的な問題を解決するための労力を減らす
  • S3は非常に良い例
  • 大抵のチームはオブジェクトストレージを必要としている
  • メッセージキューイングとSQSも同じような例
  • どのチームでもビルディングブロックを選んで問題を解決していく
• 難しい問題へ対する革新的な対処方法を探す
  • 難しい問題にあたり, 問題解決に人員を専念させる必要が出てくる
  • ネットワーク構築はこう言った問題のうちの1つである
  • ネットワークと別領域では, 大規模な分散Key-Value Storeの構築も同様に難しい問題
  • こういった難しい問題はAWSのサービスを使うことでチームへの益をもたらす
  • ここのオーディエンスがそうしているように多くのケースで, AWSは利用されている
• ベストプラクティスの公開
  • 一般的な問題であれ, 難しい問題であれ適切なビルディングブロックを探すことが大事
  • ビルディングブロック提供側は, どのように公開するかも重要になる
  • ビルディングブロックが増えれば増えるほど益を得られる反面, 選択が難しくなる
  • AWSではAWSと顧客で築き上げたベストプラクティスがあり, それを公開している

Software Delivery

Pipeline Per Team

• AmazonのSoftware Deliveryの核心部分
• 会社で1つのパイプラインのみを保持することは意味をなさないことが多い
  • 1つのアプリケーションだけを開発する場合のみうまく機能する
  • しかし複数の自立したチームがあると依存せずに高速にデプロイすることが難しくなる
• サービス単位でパイプラインを持つとうまく機能する
  • サービスごとにデプロイ方法を持っているため
  • 依存せずに高速にデプロイが可能にな
• 古典的なデプロイ方法
  • 新規ソフトウェア作成時に全てのソフトウェア更新をしようとする
  • 大規模な再起動がかかりシステムが切り替わる
• Blue/Green デプロイ
  • 新バージョンを起動してロードバランサごと切り替えるか, トラフィックの向き先を変えることでデプロイする
• Progressive Delivery(Fractional Delivery)
  • アプリケーションがより多くのサービスで構成され, より複雑になっているため, 大規模デプロイメントを安全に行うことの意味について少し考え方を変える必要がある
  • AWSへソフトウェアデプロイの大部分がFractional Deliveryで行われている
  • アプリケーションのビルドを開始するときに, まずはテストを行いパイプラインでのデプロイを開始する
  • パイプライン内での変更が予期されるものかどうかを監視するコントローラが動いており, 常に評価している
  • 監視対象は複製可能なサービス群や, 反復可能なタスク, トラフィックパターンなどが対象となり得る
  • 1リージョンの1AZ内の少量のホストに対してデプロイを行い, これを始点として本番環境で確認を行う
  • 問題があった場合はロールバックし, なかった場合は少しずつデプロイを行う
  • Progressive DeliveryはAWSのみならず, iRobot社などでも導入されている方法である

Application-first Deployment

• 重要なのはアプリケーションが依存するインフラがある場合にアプリケーションが必要とすることを考えること
  • Lambdaなどにアプリケーションとインフラを同じタイミングでデプロイするパターン
  • 低レイヤが抽象化され, アプリケーションに注力でき, 依存関係などをコンテナリゼーションできるコンテナの利点を享受するか
  • Lambdaのようにアプリケーションのプッシュタイミングで
• これを簡単に, パターンに沿って実現する方法はあるか
  • ECS CLI 2.0はベストパターンに沿って構築しパイプラインを含めて構築できるが, ほとんど出来上がったものしか構築できない
  • AWS CDKはベストプラクティスのパターンに沿って構築する機能を提供されるため,コードを書くだけでデプロイできるが, コードを書く必要が出てくる
  • SAMはCDKとパターンを組み合わせてベストプラクティスに沿った1つのテンプレートにまとめてCLIで実行するという点で似ている
  • SAMはCLIを使用することでローカル環境でのテストが可能である
  • これらのツールは全てOSSである

Operational Model

• ソフトウェアデリバリーではデプロイを安全に高速に行うことに着目した
• この章ではどのように正しいツールを選択して, 安全に運用するかについて記載する

What Our Customers Want

• 何度も考慮されて話されていることだが, アプリケーションを実行したのであって, インフラの構築や運用に時間を割きたいわけではない
• だが, ビジネス価値のあることに時間を費やすのは難しい
• 高速にシームレスにスケールしたい
• セキュリティと独立性を保って構築したい

AWS Operational Responsibility Models

• まずは責任共有モデルから考え始める
• ビルディングブロックをちょうど良いバランスで提供するのは難しく柔軟性が必要分も失われ, 使えなくなることもある
• なのでAWSは責任共有モデルを使って5層に分けてどのサービスを利用すべきかの判断材料にできるようにしている

Essential Complexity and Accidental Complextiy

• Essential Complexity
  • 避けることができない, その問題固有の複雑さ
• Accidental Complexity
  • あなたが注意することではないが, 誰かがあなたの問題として引き起こすもの
  • 本質的な問題に集中して解決のために時間を割くべきなので, Accidental Cmplexityは0に近づけるべきである

Application Should Guide Infrastructure

• コンピュータキャパシティも驚くことにサーバレスにできる
• EC2がインフラの問題を解決したように, サーバレスも同じことができ, 考慮点を減らすことができる
• FargateやLambdaなどといった

Application-first with Amazon ECS Capacity Proviiders

• "Capacity Providers for ECS"が登場した
  • ECS スケジューラとAPIに基づいてアプリケーションを配置してくれる
  • EC2インスタンスの"Auto Scaling Group"と"Fargate Capacity Providers"の2種類がある
  • タスク定義に書き込むことで設定可能
• "Fargate Spot"の登場
  • EC2スポットインスタンスのようにFargateを使用できる
  • FargateはSavling Plansの対象でもあるためディスカウントを受けることもできる
  • キャパシティの考慮はカスタマーではなく, AWSの問題にできる

Bringing Serverless Complute to Amazon EKS

• Kubernetesの運用は複雑である
• EKS on Fargateが登場した
  • PodをFargateで実行できる
  • 運用の複雑さを解消していく

Lambda Operation Controls

• VPCでLambdaを使用する際のパフォーマンス向上
  • Hyperplaneを利用して, Lambda用VPCにあるVPCへのNATとなるネットワークインタフェースとVPCのENIを繋ぐことで改善した
  • ネットワークインタフェースはVPCで固有のものを使用するため, 渡来のようにENIの作成待ちや制限が緩和される
• ストリーミング処理でのLambda使用の向上
  • "Batch Windows"の提供
  • Kinesis Data StreamsやDynamoDB Streamsでのバッチ処理タイミングをバッチサイズだけでなく時間制限を設定して行える
  • "Lambda Failure-Handling"の提供
• 非同期関数実行終了時の改善
  • "Lambda Destinations"の提供
  • Lambdaの実行結果に基づいてSNS TopicやSQS Queueにメッセージを送り込める
• Lambda Provisioned Concurrency
  • コールドスタート対策を行っていたがそれでも十分でなかった, 非常に低いレイテンシが求められるアプリケーション向けの機能
  • 事前に同時実行数を設定することで, 2桁程度のミリ秒での開始をサポートする

Savings Plan

• 事前に使用する額をコミットすることで割引をうけることができる機能
• EC2とFargateはすでに利用可能
• Lambdaが来年に追加される

Architecture Patterns

• アプリケーションのアーキテクチャパターンは結局のところ, コミュニケーションパターンになる
• "Two Pizza teams" は限られた人数のメンバーから構成されるため, 全員が互いにコミュニケーションを取り意思決定をする必要がある
• チームに関与する人が増えれば増えるほど意思決定は難しくなり, コミュニケーションマネジメントの問題となる
• "Small Pieces loosely joined" という手法では, 疎なコミュニケーション手法によって独立して変更を加えることができる
• この手法をとるアーキテクチャパターンを紹介する

APIs are Hardened Contracts

• APIはマイクロサービスにおける玄関のようなもの
• 何を渡すかに関しては保証し後ろ側については前側での振る舞いを変えない限りはどのように変更しても問題ない
• APIは強固な契約のようなものなので, 変更には大きな決断が伴うが, APIでなければ変更が容易にできる
• メトリクスの生成やスロットリング, アクセスコントロール, SDKの作成などがAPI作成時に求められる
• API Gatewayはこれらの機能を提供したり, APIの玄関としての役割を担い, 後ろにLambda関数やコンテナ, EC2インスタンス, オンプレミスを対象にすることができる

HTTP APIs(Preview)

• 最大70%のコスト削減
• 50%のレイテンシ低減
• 認証のサポート

Serverless Application

• APIはどのようにリクエストを受けてレスポンスをするかの構築には関与しない
• "Event Driven"なアーキテクチャをサーバレスで構築することが一般的
• サービスと疎になり, 依存せずにスケールできる
• 80年代後半から90年代に "Enterprise Message bus" が流行した時と同じ理由で, 複雑さに対処するために疎にしている

Event Driven Architectures

• KinesisやDynamoDB StreamsやSNS, SQSでのイベント管理のいずれにしても, AWSは運用をしサービスを提供する
• LambdaのイベントソースとしてSQS FIFO Queueが最近追加された
• SNSではDead-Letter-Queueへの配信機能が追加された
• AWSの顧客はAWS側で発生するイベントを取得したいし, AWS側にカスタムイベントを発火させたい
  • EventBridgeの登場でSaaS側のイベントをAWWS側に簡単に渡せるようになった
  • しかしイベントを作るにあたってするべきことは非常に多い
  • "schema registry and discovery" を使用することで, スキーマの公開と共有が簡単にできる

Data Streams

• 非常に強い順序保証が必要な場合にDynamoDB StreamsやKinesis Data Stremasを使用して, インタラクティブに処理を行う
• 一般的にはデータ量が多い場合にのみKinesisを使用してデータ処理を行う
• RDS Proxy
• インタラクティブにデータを処理したいが, データソースがRDBでLambdaから接続する場合に役立つ

Coordinate functino execution

• 実際のアプリケーションではサービス間での調整が必要になる
• サーバレスではとりわけ使用するサービス数が多いため, より調整が必要になる
• この問題をStep Functionsが解決する
• "Express Workflows" では1秒あたり100000イベントを超えるレートサポートなどを行う
• 再起動しても問題なければ, "Express Workflows"は良い選択肢であり, 再起動やチェックポイントの確認が許容できない場合は "Standard Workflows" を使用すると良い

さいごに

ベストプラクティスに沿ってどのようにアーキテクチャを構築するかやサーバレスとコンテナの新サービスのキャッチアップができる良いセッションでした.