10月26日開催 AWS Innovateセッション受講まとめ

はじめに

こんにちは！システム統括課インフラチームです！
10月26日にAWS Innovateが開催され、弊社メンバーにていくつかセッションを受講してきました！
今回のテーマは「モダンアプリケーション」。
分野毎にセッションが分かれておりましたが、コンテナのセッションをメインに受講したので、そちらの内容を振り返ってみたいと思います。

参加したセッション

・T3-1　なぜコンテナを選択するのか、コンテナを選択すると何が嬉しいのか
・T3-2　DevとOpsが協業できる共通基盤～AWSで始めるプラットフォーム エンジニアリング～
・T3-3　コンテナワークロードにおけるアプリケーションネットワーキングの設計パターン
・T3-4　AWS App Runnerを使う時に押さえておきたい勘所～Webアプリをコンテナに最適化する～

イベントの感想

参加したセッション毎に、まとめ・感想を述べていきたいと思います。

T3-1 なぜコンテナを選択するのか、コンテナを選択すると何が嬉しいのか

このセッションではコンテナの特性やメリット、そしてそのコンテナのメリットを享受するにはどのようにしたら良いか、という内容でした。

コンテナには以下３つの特性があり、これらによってデプロイの自動化やアプリケーションデリバリーやスケールの高速化が実現可能になるメリットがあるとの事でした。

①スピード
②柔軟性
③可搬性

上記メリットを得るにはただコンテナを利用するだけでなく、いくつかポイントが挙げられていたのですが、中でも以下のポイントは自分の認識にありませんでした。

・1プロセス1コンテナに分割する
・デプロイフローの自動化と計測

モノリシックになるのを避け、プロセス毎にコンテナを分割して必要なプロセスだけ処理に応じてスケール可能になっている状態の方が良いとは知りませんでした。

また、CodePipeLineやDeployによるデプロイフローの自動化は鉄板ですが、その後の効果測定まで実施した方が良い事までは知らなかったので、新たな知見になりました（自動化できればOKっしょ！くらいな意識でした）。

コンテナベースのアプリケーション開発の際は、上述のポイントも意識して環境構築に臨むようにしていきたいですね！

T3-2 DevとOps が協業できる共通基盤 ～ AWSで始めるプラットフォーム エンジニアリング ～

このセッションは、従来の共通基盤の課題とプラットフォームエンジニアリングとはなんぞや、共通基盤との違いは？という内容でした。

従来の共通基盤は、運用で行っている各種対応業務（デプロイやモニタリング、オンコール対応など）をパッケージ化し、アプリケーションの仕様統一を図るのが目的である一方、アプリケーション側の観点に欠けている・DevOpsの観点がない、といった課題があり、クラウドとビジネスの状況変化に対応しづらい問題がある、との事でした。

これらを解決する、DevOpsが可能な共通基盤を作成する事がプラットフォームエンジニアリングであり、AWSで実現するには以下サービスの利用をお勧めしていました。
・AWS Proton
・AWS App Runner
・AWS CDK

各サービスの説明は省きますが、AWS App Runnerは他セッションでも度々登場しており、DevOps実現に適しているサービスであると感じました。
DevOpsは変化の激しいビジネスにおいてはとても重要な観点でありますので、日々の業務にも積極的に取り入れていきたい所です。

T3-3 コンテナワークロードにおけるアプリケーションネットワーキングの設計パターン

このセッションでは主に分散システムにおけるサービス間での同期的な通信の課題に触れ、これらを解決するには採用するコンテナサービスとトラフィック経路に応じて設計パターンが異なる、という内容でした。
ただ、ネットワーク設計には工数もかかり、開発に注力するためにマネージドサービスを活用しましょうという事でした。

そこで挙げられたコンテナサービス、トラフィック経路そして設計パターンを以下に述べていきます。

・コンテナサービス
Amazon ECS
Amazon EKS
AWS App Runner

・トラフィック経路
North-South Traffic(ここではインターネットからVPCに出入りするトラフィック)
East-West Traffic(ここではVPCからVPCに出入りするトラフィック)

弊社で主に使う機会があるのがECSのため、ECSの設計パターンを重点的にまとめます。

・ELBの利用（North-South Traffic/East-West Traffic）
ELBを使用する事で、外向け・内部向け両方の通信に対応可能です。このパターンが最も多いのではないでしょうか。

・AWS App Meshの利用(East-West Traffic)
Envoyプロキシを利用してサービスを公開します。同じメッシュに所属するクライアント（EC2、ECS、Kubernetes）からのみアクセスが可能で、VPC間の通信にはVPC Peering connectionが必要になります。

・ECS Service Connectの利用(East-West Traffic)
ECS Service Connectが管理するプロキシを利用してサービスを公開します。同じ名前空間に所属するECSサービスからのみアクセス可能で、VPC Peering connectionが必要になりますが、ネットワークモデルの設計が不要であるとの事です。

・VPC Latticeの利用(East-West Traffic)
VPC Latticeと内部向けALBを利用してサービスを公開します。同じサービスネットワークに所属するVPCからのみのアクセスとなりますが、VPC Peering connectionなどが不要な点が強みです。

現状、外部向け通信に対応できるELBとの組み合わせくらいしか利用していませんが、コンテナ同士の内部通信の要件が発生した場合は、ECS Service ConnectやVPC Latticeなどは利用候補に挙げても良いなと感じました。

T3-4 AWS App Runnerを使う時に押さえておきたい勘所～Webアプリをコンテナに最適化する～

最後にこのセッションでは、度々登場してきたAWS App Runnerについての概要・ユースケース、プラクティスガイドなどの紹介が行われました。

App Runnerの特徴は、ウェブアプリに必要なインフラが構築済みであり、デプロイが迅速に行える点です。
必要な環境がフルマネージドで提供されるのでインフラの設計・構築の手間が省け、よりアプリケーション開発に注力できるようになる事がメリットになります。

代表的なユースケースとしては以下の３つが挙げられました。

1.モノリスなWebアプリ
2.モバイルアプリやシングルページアプリケーションのバックエンドAPI
3.社内向けのWebサイトやAPI

また自動デプロイを行う際にコンテナイメージだけでなく、Githubのソースコードでもデプロイが実施できるため、普段Githubを利用しているユーザーにとって嬉しい機能だと思いました。

App Runnerを使用する際のプラクティスガイドは以下のとおり。

・消えて困るデータは外部ストレージに保存
・S3やDynamoDBなどVPCに関係のないサービスにはIAMロールで制御
・VPC内にあるサービスへの接続にはVPCコネクターを設定する必要がある
・SIGTERM受信後の終了処理のハンドリング
・秘密情報の受け渡しには、AWS Secrets Managerを使う
・ログは標準出力(STDOUT)・標準エラー出力(STDERR)にする
・AWS X-Rayでトレーサビリティを確保する

フルマネージドサービスとはいえ、色々と考慮しなければならない点があるようで、もし利用するならば個人的には「社内向けのWebサイトやAPI」のユースケースが一番始めやすいかなと感じました。
いずれにせよ、インフラ構築の手間を殆ど除外できるのは大きな強みで、実際ちょっと使ってみたいなあと思うサービスでした。

まとめ

今回のAWS Innovateのテーマが「MODERN APPLICATIONS EDITION」という事で、モダンなアプリケーションとは？実現するにはどうすればよいか？というテーマでしたが、コンテナのセッションを一通り受講し、どれも「如何にビジネスの状況変化に素早く対応できるかどうか」が重要であると感じました。

人・組織にもその考えが根付くことが重要で、あくまでコンテナやサーバレスといった技術面は手段でしかないと、改めて考えさせられました。
今後もそのマインドを大事にして、スキルアップや日常業務に励んでいきたいですね。

以上、ありがとうございました。