この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「そのサーバーレス、本当に意味あるの？」
AWS re:Invent 2014で、AWS Lambdaが発表されてから丸3年が経過。サーバーレスという単語もすっかりこの界隈では定着した感はあります。
ですが、実際の開発・運用ノウハウについては、まだまだ試行錯誤が続いているのが現状じゃないでしょうか。ぶっちゃけ、既存アプリケーションのEC2をLambdaに置き換えるだけではほとんどメリット無いでしょ、という感触は、ある程度サーバーレスアプリケーションをゴリゴリ作っている人であれば、よく感じていることだと思います。
そんななか今回受講したこのデブサミのセッションでは、新しい観点でサーバーレスがもたらす恩恵やメリットを捉えることができてごっつ新鮮だったので、その模様をお届けいたします。
「これ、ほんまにサーバーレスにする意味あんのかなぁ？」など、サーバーレス導入にあたり、試行錯誤を続けている人には、参考になる点が多いのではないでしょうか。
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 ｻｰﾊﾞｰﾚｽﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
講演内容
講演者は、株式会社SUPINFの、原 康紘さん（@toricls）。
サーバーレスのメリットを最大限引き出すためのシステム設計手法と考え方。
新規か既存かを問わず、システムにサーバーレス・アーキテクチャーを適用していく際に重要となるポイントや考え方をお話しします。引用：サーバーレスのメリットを最大限引き出すためのシステム設計手法と考え方。
講演資料
以下、本文中の画像は、上記講演資料より引用させていただいております。
自己紹介と最近のサーバーレス活動
どうも、SUPINFの原 康紘です。本日は「サーバーレスのポテンシャルとシステム表現」というタイトルでお話させていただきます。タイムテーブルのタイトルと違うのは気にしないでください。はい。
好物は、サーバーレス全般や、Dockerなどのコンテナ技術です。
pingbotという、外形監視＆通知ツールや、github-codebuild-integrationという、GitHubのPRをフックしてAWS CodeBuildをキックするツールとか作ってます。まぁこれ、作ったすぐ後に公式でサポートされましたが…
あとは、LambdaでCOBOLを動かすcobolambdaなんてのも作っています。まぁ、ジョークアプリ的なあれです。
コンピューティング・リソース調達方法の歴史
これからサーバーレスアプリケーションの話をしていくわけですが、最初にコンピューティング・リソース調達方法の歴史を振り返ってみましょう。
まぁ、ざっくりこんな感じですね。物理面の調達と運用をアウトソースしていたところからさらに推し進めて、リソースそのものの調達と運用をアウトソースしたものが、サーバーレス（Lambda）と言えます。アプリケーションのみ自分たちで管理・運用します。
サーバーレスのメリット
じゃぁ、「サーバーレスのメリット」って実際なんだと思います？私の考えでは、以下の2点に集約されます。
サーバーの事前プロビジョニングや管理なし＝サービスベンダに金を払うだけで、以下のメリットを享受すること。
- 機能を得られる
- コード実行環境を得られる
それぞれのメリットの具体例を表したのがこちら。
ここに、実は一見見逃しがちなサーバーレスのメリットがあります。
Functional SaaS / BaaS
Auth0やFirebaseやSendGridなどの、いわゆるSaaS、BaaSがここに当てはまります。こういったサービスは機能性がコンポーネントとして切り出されているので、結果、マイクロサービス的な取り組みが必要とされます。例えば、サーキット・ブレイカーなどが当てはまります。
PaaS
Google App EngineやHerokuなどのいわゆるPaaSです。プラットフォーム側の運用に制約があるので、結果、アプリケーションの作りにも制約が入ります。例としては、The Twelve-Factor Appですね。これ有名なので、まだ見たことない人は是非見てみてください。日本語訳も有ります。
FaaS
最後にFaaSです。AWS Lambdaや、Azure Functionsなど。これは、完全なステートレスや冪等性をアプリケーションに要求します。有名な話ですが、このステートレスという特性は、コネクションプーリングを基本とするRDBと非常に相性が悪いですね。これらが要求されるため、ユーザーに自前でプロセス管理をさせない設計にならざるを得ません。
しかし、これら制約があるからこそ得られる利点がああるわけですよ。
プラットフォーム自体がネイティブにイベント・ドリブンとなることを要求します。
イベントドリブンアーキテクチャーとは？
ここで、最初にイベントドリブンではないアーキテクチャーを見ていきましょう。
イベントドリブンではないアーキテクチャー
受注管理サービスから、RESTで配送予約サービスや在庫管理サービスを呼び出している例です。ここに、新しく売上集計サービスを追加するとき、これだとどうしても受注管理サービスに対して修正が必要となります。
イベントドリブンなアーキテクチャー
これがイベントドリブンなシステムだとこうなります。
受注管理サービスはあらかじめイベントを起動するようにしておきます。売上集計サービスが追加されても、既存のイベントにサブスクライブするだけで対応が可能となります。
疎結合のシステムを組むためにこのアーキテクチャーが非常に便利かと思いきや、一点難点があります。イベントストリームが全てのサービスの結合点になるので、ここに全ての処理が集中してシステム負荷的につらい状況に陥ります。
ここで活用するのがクラウドってわけですよ。
いやぁ便利な世の中になったものですね。はい。
イベントドリブンなシステムをAWSで構築する例
先程説明したシステムを、AWSで実装した例はこうなります。
イベントストリームの起点としてDynamoDBを利用しています。ここからDynamoDB ストリームを利用して各サービスを起動することができます。
さらに拡張した例がこちら。
Dyanmo DBのストリームからLambdaを起動し、そこでデータを編集。その結果をKinesis Data Streamsにpublishして、それぞれのサービスを起動することもできます。
また、別の例としてはこちら。
LambdaからDynamo DBに対してデータを保存するときにTTLをつけておきます。で、一定期間経過後、そのデータが削除されたタイミングでitem deletion eventを発火させLambda経由でアーカイブするなど。一定期間経過したデータをアーカイブするにはこういった方法もあります。
サーバーレス・アーキテクチャーの真髄
最後に、「サーバーレス」アーキテクチャのシステム設計時の思考フローをご紹介します。非常に重要な点なのでよく聞いてください。
考え続けてください！いや、これまじでね。ほんとね。
何故こんなことを言っているかというと、アーキテクチャ的な利点を最大限に享受しつつ、サーバー管理からの開放を目指してもらいたいからです。
「サーバーレス」なシステムについてのまとめ
- 運用面だけではなく、アーキテクチャー面のメリットがわりとでかい
- アーキテクチャー面のメリットはプラットフォームの特性を活かすことを意識しないと得にくい
- イベント・ドリブンな形でシステムを表現できないか考える
- サービス間の相互作用をイベントとして表現できれば、サービス間が疎結合に保たれて洗練されたアーキテクチャーが手に入る
サーバーレス楽しい
最後に一つだけ良いでしょうか。既存アプリケーションの全てのサーバー側メソッドをLambdaに置き換えて、やたら大量のファンクションが存在するアプリケーションあるかと思います。基本的にアンチパターンなんで辞めておきましょうね。
それでは、原でした。
濱田感想「サーバーレスを導入することの意味を真摯に考える良いきっかけになった」
サーバーレスアーキテクチャを導入する事の最大のメリットはイベント・ドリブンの強制、という視点は非常に興味深かったです。
一般的には、サーバーがなくなることによるサーバー管理の煩わしさからの開放 → ロジックに集中できるという点がよく強調されますが、ステートレスが強制されることによるマイクロサービス的なアーキテクチャが強制され、イベントドリブン的な考えを推し進める事でよりそのメリットを最大化しようという思想は、使い込んでいる人ならではの視点だなぁと感じました。
例えば、既存のREST APIなWebサービスをAPI GatewayとLambdaに置き換えるだけってのは、サーバーレスならではのアーキテクチャの特性を十分に理解した上でやらないと、逆にデメリットしかないということもあるでしょう。また、GraphQLやAWS AppSyncなどの導入においても、このあたりの特性を意識しながらやると、自ずから良いアーキテクチャを構築することができそうです。
自分はAWS事業部のため、普段アプリケーションそのものの開発をすることはあまりないんですが、弊社にはサーバーレス開発部もあり（参考：2018年のサーバーレス開発）、サーバーレスアプリケーションのアーキテクチャ検討やデプロイ・監視・運用などを含めて、トータルでノウハウを貯めまくっているところです。
新しい技術も、一歩引いた目線でその特性を考えてみると新しい活用法が見えてくるなぁと感じた、ごっつ有用なセッションでした。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
2
