「What's Better Than Microservices? Serverless Microservices」というタイトルのウェブキャストで、Alan Williams氏 (Autodesk)、Asha Chakrabarty氏 (Amazon)、Alan Ho氏 (Apigee)らが、Apigeeエンドポイントを使いLambda関数で構築した、AWS上で動くサーバーレスマイクロサービスのアーキテクチャについて説明した。
サーバーレス（Serverless）というのは比較的目新しいアーキテクチャスタイルだ。そのコンピューティングユニットは仮想マシンではなく、イベント発生時に実行するコードをカプセル化した関数になる、とChakrabarty氏は語る。サーバーレスコンピューティングモデルの主な性質について、Williams氏は次のように述べた。コードへのフォーカス、管理すべきサーバーがない、準備・運用すべきEC2インスタンスがない、手動のスケーリングが不要、アイドルリソースがない、SSHやRDPが不要。
以下は、Autodeskが実装したサーバーレスマイクロサービスの簡単なアーキテクチャを図示したものだ（クリックで拡大）。
マイクロサービスには複数のエントリーポイントがあり、Apigeeによって管理されたHTTPエンドポイントとして公開される。ユーザーはリクエストがサーバーレスマイクロサービスで処理されることを知ることなく、HTTP呼び出しをすればよい。マイクロサービスは多数のlambda関数で構成されている。これらはPythonで書かれており、AWS SNS同期通知で互いに通信する。lambda関数は互いに独立しており、異なる言語で開発し、異なるチームで管理することができる。
lambda関数は短命なので、どこかに状態を永続化する必要がある。選択肢の一つがDynamoDBテーブルだ。テーブルへのアクセスはIAMロールで制御され、読み書きアクセスが必要な関数だけに制限される。こうすることでlambda関数に対する不要なデータ開示を避け、セキュリティ違反時のマイクロサービス界面への攻撃を低減する。そのシンプルを理由に、Autodeskは状態をDynamoDBに格納することにした。データのJSON渡しができ、サーバーインスタンスの運用が不要で、自動のスケールアップをサポートしているためだ。
図下部のDynamoDBテーブル (talr-taskstatus) は、複数のlambda関数の状態を永続化して、テーブル変更時にストリームするイベントを生成する。これらのイベントは、必要に応じて動作する別のlambda関数 (talr-validator) によりモニターされる。
AWSでサーバーレスアーキテクチャを実装するメリットについて、Williams氏は次のように述べた。
- 機敏さ。実装には数週しか要しなかった。
- 運用すべきインフラストラクチャがない。EC2やELBインスタンスは不要。セキュリティパッチも不要。
- 開発者は自分が書いたコードだけにフォーカスすればよい。
- Serverless Frameworkでコードを管理できる。
- コスト。経験上、lambdaソリューションの実行コストは、従来のクラウドアプローチのほんのわずか（~1%）で済む。EC2およびELBインスタンスを設定・監視する運用スタッフの費用をなくすことで、コストはさらに削減できる。
また、サーバーレスアーキテクチャは長期作業やサードパーティアプリケーションの実行には適していない、とWilliams氏は述べた。このような場合には、コンテナを使った方が適切だという。
セッションには、Serverless Frameworkを用いたコードの準備とAWSへのデプロイおよび実行に関するデモも含まれている。
Rate this Article
- Editor Review
- Chief Editor Action