クラウドネイティブに適した4つのアーキテクチャパターン
まず1つ目のテーマ、「クラウドネイティブなアーキテクチャ」について。西谷氏は「クラウドネイティブなアプリを考える上での大きな“流れ”があります」と切り出し、「マイクロサービス（Microservices）はクラウドネイティブと関係が深い考え方で、マーティン・ファウラー氏の提唱する“Microservices Architecture”では、そのポイントを大きく9つにまとめることができる」としました。
マイクロサービスとは、単一のアプリケーションではなく小さなサービスの組み合わせで構築するものであり、各サービスは独立し、単一でデプロイと実行が可能なものになっています。分割の単位は技術的な境界ではなく、ビジネスの遂行能力で行う（“フロント・サーバサイド・DB”ではなく、“リコメンデーション機能”という形で区切るような）ことが必要になってきます。またサービスで分割することで単一アプリにおけるインメモリのメソッド呼び出しで処理が行われなくなるため、HTTPのような軽量な手段を用いることも求められてきます。
マイクロサービスなアーキテクチャを採用することで得られる利点・考慮すべき点は双方存在します。西谷氏は「最初からマイクロサービスを踏まえた構成で作っていくと大変な部分が多い。プロジェクトの初期の段階ではモノリシック（一枚岩: ここでは“1つのアプリケーション”という意味）に作っていき、後から分割していくのが良いのではないかと思います」と個人的なこれまでの経験から得られた“向き合い方”についてアドバイスしました。
AWS上でマイクロサービスを構築する場合、主なアーキテクチャパターンは以下の4種類になります。
- （1）API Gateway + Lambda
- （2）EC2 + ECS
- （3）EC2 + Elastic Beanstalk
- （4）EC2 + ELB + Auto Scaling Group + Runtime
一般的なWebアーキテクチャ（4）を例に挙げてみます。ポイントは、アクセスがない場合でも必ずサーバを1台稼働させ続ける必要があるということ。インフラ構築後の運用面に関する課題も存在します。
これに対して“これは最もクラウドネイティブなアーキテクチャと”なる（1）のアーキテクチャ、こちらの構成では“サーバレスアーキテクチャ”という名前のとおり、ユーザーが管理すべきサーバが存在していません。ここでのポイントは構成図下部のLambdaの部分。従来はEC2上にWebサーバを導入し、サービスを処理していたものが、このアーキテクチャパターンではAPI GatewayとLambdaに置き換わります。Webサーバが必要なくなるというのが1つ大きなポイントと言えるでしょう。Lambdaファンクションから各AWSサービスを呼ぶことができるのも特徴です。
サーバレスアーキテクチャを採用することで、懸念となっていたインフラ面におけるもろもろの課題は基本的には解決する形です。インフラの構築は各サービスが適切にハンドリングしてくれるようになるため、不要となるのです。また、サーバレスアーキテクチャを採用することによるメリットも数多くあります。バックエンド側のコードやサーバが減るために開発や運用のコストが最小化されますし、AWSマネージドサービスに置き換えることで、もろもろの懸念点について心配をする必要がなくなり、多くのケースでコスト減を見込むことができます。“サーバレス”な環境になりましたが、必要に応じてEC2を導入できるという安心感もポイントです。サーバレスアーキテクチャによって、「付加価値を生まない重労働からの解放」が期待できるのです。
サーバレスな環境で利用する各種サービスは汎用的なサービスのため、サーバレスアーキテクチャが要件をすべて満たせないといったケースもありえます。そういった場合、Dockerに代表されるコンテナサービスの採用を検討するのも良いでしょう。Lambdaをバッチ処理の基盤として使いたいという要件もありますが、Lambdaはタイムアウト判定が短く設定されているため、長時間のバッチ処理には適さない場合があります。こういったケースではコンテナを有効活用できるでしょう。AWSでは複数コンテナをEC2クラスタ上で一元管理できるサービスとしてECS（Amazon EC2 Container Service）を利用可能です。
