サーバレスアーキテクチャを実戦投入するにあたって知るべきこと

1. サーバレスアーキテクチャを実戦投入するにあたって知るべきこと 2017.09.27. 三宅暁

2. 自己紹介三宅暁(AKIRA‑MIYAKE) フロントエンドが得意だけれども、AWSとかDockerとかiOSとかいろいろ触ったりするエンジニア GitHub: https://github.com/AKIRA‑MIYAKE Blog: http://dream‑of‑electric‑cat.hatenablog.com/ Twitter: @DreamOfEleCat

3. 今日話すことサーバレスアーキテクチャとはサーバレスアーキテクチャの向き不向き AWSでのサーバレスアーキテクチャ開発

4. サーバレスアーキテクチャとは

5. MartinFolwer.comの記事より Serverless Architectures サーバレスとは、アプリケーション開発者がいくらかのサーバサイドのロジックを作成しているアプリケーションであるが、従来のアーキテクチャとは異なり以下のようなコンテナでロジックが実行される。イベントをトリガーとして起動される短命(1回の呼び出しで破棄される) サードパーティーによるフルマネージド

6. 各プラットフォームの説明 Amazon Web Service 高可用性を実現しながら、アプリケーションの実行およびスケーリングに必要なことがすべて自動的に行われます。 Microsoft Azure イベントドリブン型のサーバーレスコンピューティングエクスペリエンスにより、開発を高速化できます。 Google Cloud Platform どこでイベントが発生しても、それに応答してオンデマンドでロジックを起動できます。 IBM Bluemix 着信イベントに応答して機能を実行するFunction‑as‑a‑Service (FaaS) プラットフォームです。

7. キーワードイベントドリブンステートレス

8. イベントドリブンイベントに応じてロジックが起動されるイベントを受信したプラットフォームが、コンテナを起動してコードを実行する Webサーバのようなリクエストを受け付ける常駐プロセスが存在しないコードの実行時間に対して課金される理由

9. ステートレスなコンテナスケールしやすい (外部にボトルネックがなければ)単純にイベントに応じて起動数を増やせばいい外部リソースにアクセスしないコードであれば、理論上無限にスケール可能コードレベルでは、グローバル変数に依存しないため複雑性を排除できる 1つのコンテナでエラーが発生しても、他のコンテナに影響を与えない

10. まとめるとイベントドリブンで実行されるステートレスなコードを組み合わせて、アプリケーションを構築するアーキテクチャスケールしやすく、耐障害性にすぐれる各コードは疎結合であるため、構成変更に対応しやすいリアクティブ宣言即応性、耐障害性、弾力性、メッセージ駆動 The Twelve‑Factor Appのスケーラビリティや耐障害性を確保するための項目を、いわばコードレベルで強制されるアーキテクチャ

11. サーバレスアーキテクチャの向き不向き

12. サーバレスアーキテクチャのデメリットステートレス状態を扱う場合は必ず外部のデータストアを用いる必要があるが、それらへのアクセスはサーバのメモリやストレージへのアクセスと比較して低速オンデマンドの起動イベントのたびにコンテナを起動するため、オーバーヘッドが存在する VMの起動を要するJavaやC#はその影響が顕著 JITコンパイラの適応的コンパイルの恩恵を受けることができない各プラットフォームごとに、起動済みコンテナを再利用する仕組みがあるにはある

13. サーバレスアーキテクチャのデメリット実行時間の制限多くのプラットフォームでは5分程度でコンテナが破棄されるベンダーロックイン現時点では各プラットフォームごとに固有の形式でコードを記述する必要があるイベントと関数の紐付けはプラットフォームで閉じている Serverless Event Gatewayはそれを解消しようとしているように見える

14. 向いている用途イベントに対する単純な処理ストレージに保存された画像のサムネイルの作成データベースに値が追加された際に外部のAPIに値を送信する REST APIのバックエンドもともとRESTの設計原則が、ステートレスなクライアント/サーバプロトコルであるためクライアントサイドでのN+1問題の発生に気をつける

15. 向いていない用途ゲームなどリアルタイム性を要求されるバックエンドデータストアへのアクセスがボトルネックにコンテナ起動時のオーバーヘッドが無視できなくなる長時間のバッチ処理実行時間の制限にひっかかる再帰的な呼び出しで解決できるかもしれないが、難易度は高い Azureには常時コンテナを立ち上げておくプランがあるが、それはサーバレスト言えるのかどうか

16. AWSでのサーバレスアーキテクチャ開発

17. サーバレスの適用範囲コンシューマ向けWebアプリのバックエンド全体 API Gateway + LambdaでAPIを提供データストアはDynamoDBとElasticsearch フロントはAngular4のSPA S3 + CloudFrontで静的コンテンツを配信

18. 言語の選択 AWS LambdaはPython、Node.js、Java、C#をサポート現時点ではNode.jsがおすすめ TypeScriptやFlowなど、静的型チェックが可能 JavaやC#はVM起動時のオーバヘッドが存在公式ライブラリやサンプルが一番充実しているような気がする参考: AWS Lambdaの処理性能を言語毎に測ってみた

19. 展開/パッケージ化 Serverless Framework インフラの構築、コードのパッケージ化、デプロイを行うオープンソースのCLIツール AWS Lambda, Microsoft Azure, Google Cloud Platform、 IBM OpenWhiskに対応構成を serverless.yml というYAML形式のファイルで定義 AWSに関しては新機能の取り込みは早いプラグイン形式で機能拡張が可能 AWS SAM AWS公式のCLIツール CloudFormationのテンプレートを用いて展開 zipファイルの生成などは手動

20. AWSに存在するいくつかの制約 AWS Lambda 関数名は64文字まで Serverlessは ${service-name}-${stage}-${function- name} という関数の命名をするため注意が必要 CloudFormation リソースの最大数は200までそれなりの規模のAPIバックエンドの場合、サービスを分割しなければいけない API Gateway 複数のAPIをカスタムドメインにマッピングする場合、一意のベースパスが必要 CloudFormationの制約でサービスを分割する際は、そのことに留意

21. バージョン管理 Serverlessを利用しているのであれば、構成も含めてバージョン管理できる Lambda関数自体にもバージョン管理の機能がある Serverlessはデフォルトでオンデプロイごとにバージョン番号が振られるリージョンごとにデプロイパッケージの合計サイズが 75GBの制限がありバージョン管理ツールで管理しているのならオフでいいかも複数の関数にまたがるアトミックなデプロイ、ロールバックの機能はない稼働中のサービスに対する大規模なデプロイの際は注意 2系統用意し、API Gatewayのカスタムドメインで呼び出し先を切り替えるブルーグリーン・デプロイとか

22. 環境変数 Lambdaのコンソールで環境変数を追加・設定が可能 Serverlessの管理ファイルからもキーバリューの組み合わせを設定できるコードからは process.env.{KEY} でアクセスセンシティブなデータはKMSで暗号化を参考: KMSで認証情報を暗号化しLambda実行時に復号化する

23. ステージにより異なる環境変数の設定 serverless.yml は ${env:KEY} でローカルの環境変数にアクセスできる docker‑composeは env_file で指定したファイルの値を環境変数に追加する docker‑composeは ${ENV_FILE} のようにホスト環境の環境変数にアクセスできる各ステージの .env.{stage} ファイルを定義 ENV_FILE={.env.stage} docker-compose up のように、ファイルを指定してDockerを起動 Serverlessは追加された環境変数を利用

24. フレームワーク

25. いわゆるWebフレームワークはない http.request や http.response を扱うわけではないので、既存のフレームワークは使えない ExpressなんかをLambda上でで動かすことはできるけれども、オーバーヘッドが大きい

26. なければ自分で作ればいいのよ!

27. Lamprox AKIRA‑MIYAKE/lamprox lambda‑proxyでAPIを開発するためのミニマルなフレームワーク API Gatewayが要求する形式のレスポンスを自動で生成 http‑errorsの型でエラー時のレスポンスをハンドリング const mainProcess = (ambience: ProcessAmbience) => { const responseBody = { input: ambience.lambda.event.body } return Promise.resolve(responseBody) }

28. lambda‑utilities AKIRA‑MIYAKE/node‑lambda‑utilities Lambda関数を開発する際に汎用的に使うことのできる型定義テストのためのユーティティ関数

29. serverless‑import‑swagger AKIRA‑MIYAKE/serverless‑import‑swagger SwaggerのAPI定義をserverless.ymlにインポートするCLIツール Swagger Codegenが生成したクライアントのモデルを、Lambda 側のAPIレスポンスの静的な型付けチェックに利用

30. テスト lambda‑utilities generateMockCallback() generateMockContext() invokeHandler() sinonを利用したモックの生成関数とハンドラの実行関数を提供 const callback = generateMockCallback((error, result) => { callback.once() assert.equal(result.foo, 42) assert.ok(callback.verify()) done() }) invokeHandler(handler, { event: { foo: 21 }, callback: callback })

31. テスト lamprox generateDummyAPIGatewayEvent() generateProcessAmbience() Processは Promise を返す設計なので、引数さえ渡せばテストは容易 const ambience = generateProcessAmbience({ event: generateDummyAPIGatewayEvent(), context: generateDummyContext(), callback: generateMockCallback(), result: 21, environments: undefined, }) return mainProcess(ambience) .then(result => { assert.equal(result.value, 42) })

32. テストテストランナーにはMochaを利用設定が簡単ブラウザで実行する必要がないためアサーションライブラリはお好みで

33. テストをしやすくするために外部リソースに依存する箇所は切り出す Stubに置き換えてテストできるように依存性は注入できるようにテスト時はStubを注入自分は外部リソースにアクセスするクライアントをまとめたオブジェクトを、引数で明示的に渡すスタイルをとっているデプロイして動かしてみるという割り切りも必要

34. ロギング Lambda関数は異常終了した際はエラーログを出力しないコンテナ自体が落ちるため失敗する可能性のある処理のエラーハンドリングは確実に未定義の変数へのアクセスなどを、静的にチェックできる TypeScriptの恩恵が大きいログ出力用の関数をあらかじめ用意し、それをインポートして使う process.env.ENV などと組み合わせて、ログレベルはその関数で制御

35. CI (Continuous Integration) AKIRA‑MIYAKE/serverless‑typescript‑starter DockerでServerless Frameworkのdeployコマンドを実行 deploy: "cd /serverless-app/src/service/api && sls deploy" みたいなデプロイタスクを package.json に追加することが多い

36. まとめ

37. アプリケーションのちょっとした処理なら非常に有効イベントドリブンの非同期な処理とかデータ更新などをトリガにする処理を疎結合にできるのは魅力全面的に採用するは今現在では覚悟が必要フレームワークを自分で作れるレベルの人が、コアを作り込む必要がある得られるメリットも大きい高い可用性と耐障害性関数単位でデプロイを行えることによるアジリティの向上関数単位でリソース割り当てを設定できることによる、コスト最適化

38. Thank you for listening!

サーバレスアーキテクチャを実戦投入するにあたって知るべきこと

暁 三宅

サーバレスアーキテクチャを実戦投入するにあたって知るべきこと

暁三宅