【レポート】コンテナ・サーバーレスを使えばモダンアプリケーションになりますか？ #AWS-27 #AWSSummit
こんにちは、CX事業本部MADチームのかずえです。
MADチームというのはModern Application Developmentチームの略です。決して「狂った」とか「怒った」とか言う意味ではありません。で、「何をしてるチームなんですか？」と訊かれると、「サーバーレスやコンテナを専門に扱うチームです」と答えることが多いです。
ですがこのセッションにあるとおり、サーバーレスやコンテナを使う=モダンアプリケーションという場合ばかりでは無いようです。そもそもモダンアプリケーションというものに対する私の理解がふわっとしています。。真の意味でModern Application Developmentができるようになりたいと思いこちらのセッションを聴講しました。
セッション概要
「とりあえずサービスをコンテナ化してモダナイズしました」「AWS Lambda を使ったモダンアプリケーションです」本当にコンテナやサーバーレスを使うだけでモダンアプリケーションとなるのでしょうか？そもそもモダンアプリケーションとは何でしょうか？このセッションは、アプリケーションをモダナイズする第一歩としていただくためのセッションです。AWS 上でモダンアプリケーション開発をしていく上でのアーキテクチャや実装パターンについても紹介します。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 西日本ソリューション部 ソリューションアーキテクト 濱 真一 氏
セッションページURL
セッション内容
モダンアプリケーションとは︖
素早いイノベーションによって競争的差別化を作り出す⼿段となるもの
まず、昨今のビジネスシーンにおいては市場の変化に素早く対応する必要がある、という前提があります。で、変化に素早く対応するためには、実験/傾聴/アイデアのループを高速に回していく事が必要になります。このループを素早く回し続けるために必要な要素を持ったアプリケーションがモダンアプリケーションです。
モダンアプリケーションに求められるもの
- 数百万のユーザーに迅速にスケール
- グローバルレベルの可⽤性/たとえシステムの一部に障害が発生してもサービスを継続できる弾力性
- 数ミリ秒で応答できる俊敏性
- ペタバイトクラスのデータをハンドル
必ずしもすべてのアプリがモダンアプリケーション化する必要はありません。例えば継続的なイノベーションが不要な、塩漬けするようなシステムだと必要性が薄いです。
モダンアプリケーション構築の最適な⽅法
以下のいくつかを組み合わせることで実現可能
- アーキテクチャパターン
→サービスのモジュール化 - 運用モデル
→できる限りマネージドなものを使う - ソフトウェアデリバリー
→自動化と標準化 - 管理とガバナンス
→組織全員で責任を持つ - データ管理
→目的に合ったデータストアを使う
モダンアプリケーションにとってのコンテナ・サーバーレス
以下アプリを例に、モダンアプリケーションを作成するにあたってコンテナ・サーバーレスを採用するモチベーションについて説明します。
上記例はコンテナ・サーバーレスを使わず代わりにEC2を使って構成されています。この場合でも前述のモダンアプリケーションの手法をいくつか採用していることがわかります。
- DBを目的別に使い分けている
- サービスごとにEC2を分割し、それぞれがAuto Scalingでスケールできるようにしている
一方でこの構成には改善できる箇所も残されています。
- 仮想マシンの管理・運⽤コスト
- 余剰なリソースを確保しておく必要がある
- 密結合なアーキテクチャで伸縮性や弾⼒性の限界がある
- モジュール化されたサービスの可観測性
- デプロイの⾃動化/継続性
このうち、上記2つ(仮想マシンの管理・運⽤コスト/余剰なリソースを確保しておく必要がある)については、コンテナ・サーバーレスを活用することで改善でき得ます。他の3つの要素についてもコンテナ・サーバーレスを使えば必ず改善できるとは言えませんが、改善しやすくなると言えます。
上記表の通り、AWSには様々なコンピュートサービスがあります。上部のサービスに行くほどお客様がやること=運用コストは少なくて済みますが、反面コントロールできることが減ると言うことにもなります。ワークロードに合ったサービスを選定することが肝要です。
先程の構成をコンテナ・サーバーレスを使って改善してみました。
- 静的コンテンツはS3のウェブサイトホスティング
- API部分はAPI Gatewayをエンドポイントに
- Service1をLambda関数化
- Service2はECS Fargate化
これにより、前述の課題のうち上2つは大方改善できました。
仮想マシンの管理・運⽤コスト余剰なリソースを確保しておく必要がある- 密結合なアーキテクチャで伸縮性や弾⼒性の限界がある
- モジュール化されたサービスの可観測性
- デプロイの⾃動化/継続性
しかしそれだけでは残り3つも残っています。つまりコンテナ・サーバーレスを使うことはモダンアプリケーションのいち要素に過ぎません。コンポーネントを置き換えるだけでなく、その技術やサービスに最適化された設計や運用モデルを使うことで、モダナイズはやりやすくなります。 自分たちのワークロードの技術的部分だけでなく、ビジネスや組織など広い視野を持ってアーキテクチャや実装をデザインすることが重要です。
モダンアプリケーションのデザインパターン
- 巷にはたくさんのキーワードが溢れている。どれをどのように使えば?
- 代表的なものをいくつか紹介します
伸縮性・弾⼒性を⾼めるデザイン
- コマンドクエリ責任分離（CQRS）
- イベントソーシング
- キャッシュ分離
- ⾮同期リクエスト・レスポンス
- パブリッシュ・サブスクライブ
- コレオグラフィ
- メッセージキュー
- シャーディング
- 静的WEB ホスティング
モジュール化されたサービスの可観測性
ログ/メトリクス・トレースといったモニタリングデータはアプリ内部に保持せず、イベントストリームとしてクラウド上に集約してモニタリングするのが良いです。
デプロイの⾃動化/継続性
CI/CDパイプラインの作成を是非ご検討ください。変化に迅速に対応するためのモダンアプリケーションという観点において、CI/CDの自動化は不可欠です。AWSにはこの分野において多様なサービスが用意されています。
別のセッションにてこの内容にフォーカスしていますので、詳細はそちらを御覧ください。
Beyond the Twelve Factor Appが参考になる
まずは自分たちのアプリケーションがどこまでこの基準に準拠できているか確認するところ始めると良いです。
感想
小並感がありますが、やはり「なぜその技術を使うのか」という点に対してしっかりと答えを持つ必要があるなと感じました。そしてその判断材料となるのは技術的な要件だけではなく、ビジネス要件や組織構造などでもあるということですね。単なる技術馬鹿では優れた設計はできないということで、私達システムインテグレータも顧客と密に連携を取ることが重要である、と感じました。
![[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
