re:Invent2015でのマイクロサービスに関するまとめと私見

丹内です。日本に戻ってきました。
今回参加したre:Invent 2015のうち、ECS/Lambda/マイクロサービスに関するブログが以下のものになります。

• (レポート)BDT312: ポストサーバーの世界におけるアプリケーションモニタリング:データコンテキストが重要な理由 #reinvent
• (レポート) DVO308: 本稼働環境のDockerおよびECS:インフラストラクチャをHerokuからAWSに移行した方法 #reinvent
• (レポート) ARC309: モノリシックからマイクロサービスへ:クラウド内のアーキテクチャパターンの進化 #reinvent
• (レポート)DVO305: コンテナを使用した継続的なデプロイメントパイプラインの加速 #reinvent
• (レポート)ARC308: AWS Lambdaを使用している、サーバーのない企業:AWSによるストリーミングアーキテクチャー #reinvent
• (レポート)DVO317: Local Docker開発から実稼働デプロイメントまで #reinvent

今回のre:InventではIoTやMobileHubの大型リリース、LambdaやKinesisのアップデートなどが熱かった影で、この「ECS/Lambda/マイクロサービス」のセッションも数が多く、どれも長蛇の列でした。

ECS/Lambda/マイクロサービス

ECS(EC2 Container Service)は、複数のDockerコンテナをEC2上で動かすことをサポートするサービスです。
Lambdaは、計算処理の単位でEC2を使うサービスです。
この2つは別のサービスで、re:Inventに参加するまでは特に関連を感じていませんでした。ECSはDockerコンテナを動かすという点ではElasticBeanstalkのDockerコンテナと似たようなものかなという印象でしたし、Lambdaは単純な処理を格安で実行できたりCloudFormationのラストワンマイルという印象でした。
なのでre:Inventが始まるまでは、特にECSやLambdaのセッションにここまで出ようとは思っていなかったですし、新しいサービスに関連するセッションがあったらそっちに行こうと思っていました。

しかし、Lambdaのセッションで以下の言葉を聞いてその意識が根底から変わります。

LambdaFunction is microservices without servers

以下のスライドを御覧ください。(レポート)ARC308: AWS Lambdaを使用している、サーバーのない企業:AWSによるストリーミングアーキテクチャー #reinventのスライドです。

EC2で動いているこれまでのアプリケーションは以下の様に表せます。1台のインスタンスに複数のサーバサイドアプリケーションが含まれています。

これがECS上のコンテナになったものが以下の図です。1つのコンテナに1つまたは関連するアプリケーションコードが入っていて、そのコンテナが1つのインスタンスに複数配置されています。

ここからコンテナとインスタンスの考え方を外したのが以下の図です。1コンテナ1アプリケーションコードを徹底していくと、コンテナ内は「Function」と呼べる小さな単位のコードになります。

現在のAWSでこれをどう実装するかというと、それがLambdaです。

つまり、LambdaはECSによるマイクロサービスを徹底して行った延長線上であって、アプリケーションコードの1つであるとも考えることができます。

実際にセッションを見て

ECS/Lambda/マイクロサービスと名前に付いているどの発表を見ても、Blueprintでも何でもなく、実際にやってみてどうだったかという事例に基づいたセッションでした。
聴講者が多かったあたりから「やりたいけどできていない」「興味はあるけど特にやってない、うまくいってない」という会社も多いのかなという印象ですが、しかし実際に商用環境での実績が出始めているということだと思います。

ECSからLambda、そしてその先へ

既存サービスからアプリケーションをいきなりLambdaに切り出すのは難しいと思います。しかし、例えば次の新規開発案件ではマイクロサービス化してECSで動かす、ということはできるかもしれません。
そうして作っているうちに「これLambdaにしてもいいかも」というサービスと、それを管理できるツールが出揃ったらLambdaFunctionに切り出して行くのが、一番現実的なのかなと思います。
さらに、もしかしたらそうして書いたLambda FunctionがAWSに正式に機能として実装されるかもしれません。そうなったらLambda Functionにデプロイしているサービスを削除して、依存サービスを書き換えれば完全に手がかからなくなるのでしょう。

実際にマイクロサービスをやるために

セッションにもあったのですが、マイクロサービスで作る上では非機能要件の実装が多くありそうでした。

• 12Factor
• 内部APIのスロットリングや認証
• サービスごとにビルドパイプラインの管理

これらの要件は、自分でコードとして実装しなくてもAPI GatewayやECSを使って実現可能です。
AWSでできることは、自分でやらずにAWSでやったほうが良いです。

また、サービスディスカバリや設定の管理などは、NetflixのOSS群を使っても良いと思いました。
これらもAWSでできるとは思うのですが、私のようにマイクロサービスや分散アプリケーションを作った経験がないうちは、「そもそも何をすればよいかわからない」という状態からのスタートだと思います。その場合は先駆者に乗っかって経験を積んだほうがよいかもしれません。これらはSpring BootというJavaのフレームワークを使うのが良さそうです。

(レポート)BDT312: ポストサーバーの世界におけるアプリケーションモニタリング:データコンテキストが重要な理由 #reinventでもあったとおり、マイクロサービスのLambda化をする際の課題の1つとして、監視が挙げられます。デプロイや管理はJAWSフレームワークなどツールによって解決できそうですが、この分野は経験がモノを言うところもあり、実際にやってみないとわからないかなと思います。

まとめ