Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
サーバレスアーキテクチャを実戦投入するに
あたって知るべきこと
2017.09.27. 三宅暁
自己紹介
三宅暁(AKIRA‑MIYAKE)
フロントエンドが得意だけれども、AWSとかDockerとかiOSとかいろい
ろ触ったりするエンジニア
GitHub: https://github.com/AKIRA‑MIYAKE
Blog: ht...
今日話すこと
サーバレスアーキテクチャとは
サーバレスアーキテクチャの向き不向き
AWSでのサーバレスアーキテクチャ開発
サーバレスアーキテクチャとは
MartinFolwer.comの記事より
Serverless Architectures
サーバレスとは、アプリケーション開発者がいくらかのサーバサイドの
ロジックを作成しているアプリケーションであるが、従来のアーキテク
チャとは異なり以下...
各プラットフォームの説明
Amazon Web Service
高可用性を実現しながら、アプリケーションの実行およびスケーリング
に必要なことがすべて自動的に行われます。
Microsoft Azure
イベントドリブン型のサーバーレスコンピュ...
キーワード
イベントドリブン
ステートレス
イベントドリブン
イベントに応じてロジックが起動される
イベントを受信したプラットフォームが、コンテナを起動してコー
ドを実行する
Webサーバのようなリクエストを受け付ける常駐プロセスが存
在しない
コードの実行時間に対して課金される理由
ステートレスなコンテナ
スケールしやすい
(外部にボトルネックがなければ)単純にイベントに応じて起動
数を増やせばいい
外部リソースにアクセスしないコードであれば、理論上無限に
スケール可能
コードレベルでは、グローバル変数に依存しないため複雑...
まとめると
イベントドリブンで実行されるステートレスなコードを組み合わせ
て、アプリケーションを構築するアーキテクチャ
スケールしやすく、耐障害性にすぐれる
各コードは疎結合であるため、構成変更に対応しやすい
リアクティブ宣言
即応性、耐障害性...
サーバレスアーキテクチャの向き不向き
サーバレスアーキテクチャのデメリット
ステートレス
状態を扱う場合は必ず外部のデータストアを用いる必要がある
が、それらへのアクセスはサーバのメモリやストレージへのア
クセスと比較して低速
オンデマンドの起動
イベントのたびにコンテナを起動する...
サーバレスアーキテクチャのデメリット
実行時間の制限
多くのプラットフォームでは5分程度でコンテナが破棄される
ベンダーロックイン
現時点では各プラットフォームごとに固有の形式でコードを記
述する必要がある
イベントと関数の紐付けはプラットフォ...
向いている用途
イベントに対する単純な処理
ストレージに保存された画像のサムネイルの作成
データベースに値が追加された際に外部のAPIに値を送信する
REST APIのバックエンド
もともとRESTの設計原則が、ステートレスなクライアント/サ
...
向いていない用途
ゲームなどリアルタイム性を要求されるバックエンド
データストアへのアクセスがボトルネックに
コンテナ起動時のオーバーヘッドが無視できなくなる
長時間のバッチ処理
実行時間の制限にひっかかる
再帰的な呼び出しで解決できるかもしれ...
AWSでのサーバレスアーキテクチャ開発
サーバレスの適用範囲
コンシューマ向けWebアプリのバックエンド全体
API Gateway + LambdaでAPIを提供
データストアはDynamoDBとElasticsearch
フロントはAngular4のSPA
S3 + CloudF...
言語の選択
AWS LambdaはPython、Node.js、Java、C#をサポート
現時点ではNode.jsがおすすめ
TypeScriptやFlowなど、静的型チェックが可能
JavaやC#はVM起動時のオーバヘッドが存在
公式ライブラ...
展開/パッケージ化
Serverless Framework
インフラの構築、コードのパッケージ化、デプロイを行うオー
プンソースのCLIツール
AWS Lambda, Microsoft Azure, Google Cloud Platfor...
AWSに存在するいくつかの制約
AWS Lambda
関数名は64文字まで
Serverlessは ${service-name}-${stage}-${function-
name} という関数の命名をするため注意が必要
CloudForma...
バージョン管理
Serverlessを利用しているのであれば、構成も含めてバージョン管
理できる
Lambda関数自体にもバージョン管理の機能がある
Serverlessはデフォルトでオン
デプロイごとにバージョン番号が振られる
リージョンごと...
環境変数
Lambdaのコンソールで環境変数を追加・設定が可能
Serverlessの管理ファイルからもキーバリューの組み合わせを設定
できる
コードからは process.env.{KEY} でアクセス
センシティブなデータはKMSで暗号化を...
ステージにより異なる環境変数の設定
 serverless.yml は ${env:KEY} でローカルの環境変数にアクセ
スできる
docker‑composeは env_file で指定したファイルの値を環境変数
に追加する
docker‑...
フレームワーク
いわゆるWebフレームワークはない
 http.request や http.response を扱うわけではないので、既存
のフレームワークは使えない
ExpressなんかをLambda上でで動かすことはできるけれども、オ
ーバーヘッドが大きい
なければ自分で作ればいいのよ!
Lamprox
AKIRA‑MIYAKE/lamprox
lambda‑proxyでAPIを開発するためのミニマルなフレームワーク
API Gatewayが要求する形式のレスポンスを自動で生成
http‑errorsの型でエラー時のレスポンスを...
lambda‑utilities
AKIRA‑MIYAKE/node‑lambda‑utilities
Lambda関数を開発する際に汎用的に使うことのできる型定義
テストのためのユーティティ関数
serverless‑import‑swagger
AKIRA‑MIYAKE/serverless‑import‑swagger
SwaggerのAPI定義をserverless.ymlにインポートするCLIツール
Swagger Codege...
テスト
lambda‑utilities
 generateMockCallback() 
 generateMockContext() 
 invokeHandler() 
sinonを利用したモックの生成関数とハンドラの実行関数を提供
co...
テスト
lamprox
 generateDummyAPIGatewayEvent() 
 generateProcessAmbience() 
Processは Promise を返す設計なので、引数さえ渡せばテストは容易
const amb...
テスト
テストランナーにはMochaを利用
設定が簡単
ブラウザで実行する必要がないため
アサーションライブラリはお好みで
テストをしやすくするために
外部リソースに依存する箇所は切り出す
Stubに置き換えてテストできるように
依存性は注入できるように
テスト時はStubを注入
自分は外部リソースにアクセスするクライアントをまとめたオ
ブジェクトを、引数で明示的に...
ロギング
Lambda関数は異常終了した際はエラーログを出力しない
コンテナ自体が落ちるため
失敗する可能性のある処理のエラーハンドリングは確実に
未定義の変数へのアクセスなどを、静的にチェックできる
TypeScriptの恩恵が大きい
ログ出...
CI (Continuous Integration)
AKIRA‑MIYAKE/serverless‑typescript‑starter
DockerでServerless Frameworkのdeployコマンドを実行
 deploy: ...
まとめ
アプリケーションのちょっとした処理なら非常に有効
イベントドリブンの非同期な処理とか
データ更新などをトリガにする処理を疎結合にできるのは魅力
全面的に採用するは今現在では覚悟が必要
フレームワークを自分で作れるレベルの人が、コアを作り込む
必...
Thank you for listening!
サーバレスアーキテクチャを実戦投入するにあたって知るべきこと
Upcoming SlideShare
Loading in …5
×

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

8,449 views

Published on

サーバーレスアーキテクチャ、AWS LambdaやAzure Functions、Google Cloud FunctionsなどのクラウドのFunction-as-a-Service(FaaS)を利用した、サーバを使わずにアプリケーションを構築する手法が注目を集めており、導入した事例も見聞きするようになってきました。

しかし、サーバレスアーキテクチャの特性や、それによって得ることのできるメリットはなにかということはあまり議論されていません。 また、これまでと全く異なるアーキテクチャ上でどのようにアプリケーションを構築するか、といった情報はまだまだ多くありません。

今回は、実際にAWSを用いたサーバレスアーキテクチャでアプリケーションを構築した際に得られた知見をもとに、私の考えるサーバレスアーキテクチャのメリット、アプリケーションを構築するにあたって気をつけるべきことなどについてお伝えします。

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. サーバレスアーキテクチャを実戦投入するに あたって知るべきこと 2017.09.27. 三宅暁
  2. 2. 自己紹介 三宅暁(AKIRA‑MIYAKE) フロントエンドが得意だけれども、AWSとかDockerとかiOSとかいろい ろ触ったりするエンジニア GitHub: https://github.com/AKIRA‑MIYAKE Blog: http://dream‑of‑electric‑cat.hatenablog.com/ Twitter: @DreamOfEleCat
  3. 3. 今日話すこと サーバレスアーキテクチャとは サーバレスアーキテクチャの向き不向き AWSでのサーバレスアーキテクチャ開発
  4. 4. サーバレスアーキテクチャとは
  5. 5. MartinFolwer.comの記事より Serverless Architectures サーバレスとは、アプリケーション開発者がいくらかのサーバサイドの ロジックを作成しているアプリケーションであるが、従来のアーキテク チャとは異なり以下のようなコンテナでロジックが実行される。 イベントをトリガーとして起動される 短命(1回の呼び出しで破棄される) サードパーティーによるフルマネージド
  6. 6. 各プラットフォームの説明 Amazon Web Service 高可用性を実現しながら、アプリケーションの実行およびスケーリング に必要なことがすべて自動的に行われます。 Microsoft Azure イベントドリブン型のサーバーレスコンピューティングエクスペリエン スにより、開発を高速化できます。 Google Cloud Platform どこでイベントが発生しても、それに応答してオンデマンドでロジック を起動できます。 IBM Bluemix 着信イベントに応答して機能を実行するFunction‑as‑a‑Service (FaaS) プラットフォームです。
  7. 7. キーワード イベントドリブン ステートレス
  8. 8. イベントドリブン イベントに応じてロジックが起動される イベントを受信したプラットフォームが、コンテナを起動してコー ドを実行する Webサーバのようなリクエストを受け付ける常駐プロセスが存 在しない コードの実行時間に対して課金される理由
  9. 9. ステートレスなコンテナ スケールしやすい (外部にボトルネックがなければ)単純にイベントに応じて起動 数を増やせばいい 外部リソースにアクセスしないコードであれば、理論上無限に スケール可能 コードレベルでは、グローバル変数に依存しないため複雑性を排除 できる 1つのコンテナでエラーが発生しても、他のコンテナに影響を与え ない
  10. 10. まとめると イベントドリブンで実行されるステートレスなコードを組み合わせ て、アプリケーションを構築するアーキテクチャ スケールしやすく、耐障害性にすぐれる 各コードは疎結合であるため、構成変更に対応しやすい リアクティブ宣言 即応性、耐障害性、弾力性、メッセージ駆動 The Twelve‑Factor Appのスケーラビリティや耐障害性を確保する ための項目を、いわばコードレベルで強制されるアーキテクチャ
  11. 11. サーバレスアーキテクチャの向き不向き
  12. 12. サーバレスアーキテクチャのデメリット ステートレス 状態を扱う場合は必ず外部のデータストアを用いる必要がある が、それらへのアクセスはサーバのメモリやストレージへのア クセスと比較して低速 オンデマンドの起動 イベントのたびにコンテナを起動するため、オーバーヘッドが 存在する VMの起動を要するJavaやC#はその影響が顕著 JITコンパイラの適応的コンパイルの恩恵を受けることができ ない 各プラットフォームごとに、起動済みコンテナを再利用する仕 組みがあるにはある
  13. 13. サーバレスアーキテクチャのデメリット 実行時間の制限 多くのプラットフォームでは5分程度でコンテナが破棄される ベンダーロックイン 現時点では各プラットフォームごとに固有の形式でコードを記 述する必要がある イベントと関数の紐付けはプラットフォームで閉じている Serverless Event Gatewayはそれを解消しようとしているよう に見える
  14. 14. 向いている用途 イベントに対する単純な処理 ストレージに保存された画像のサムネイルの作成 データベースに値が追加された際に外部のAPIに値を送信する REST APIのバックエンド もともとRESTの設計原則が、ステートレスなクライアント/サ ーバプロトコルであるため クライアントサイドでのN+1問題の発生に気をつける
  15. 15. 向いていない用途 ゲームなどリアルタイム性を要求されるバックエンド データストアへのアクセスがボトルネックに コンテナ起動時のオーバーヘッドが無視できなくなる 長時間のバッチ処理 実行時間の制限にひっかかる 再帰的な呼び出しで解決できるかもしれないが、難易度は高い Azureには常時コンテナを立ち上げておくプランがあるが、そ れはサーバレスト言えるのかどうか
  16. 16. AWSでのサーバレスアーキテクチャ開発
  17. 17. サーバレスの適用範囲 コンシューマ向けWebアプリのバックエンド全体 API Gateway + LambdaでAPIを提供 データストアはDynamoDBとElasticsearch フロントはAngular4のSPA S3 + CloudFrontで静的コンテンツを配信
  18. 18. 言語の選択 AWS LambdaはPython、Node.js、Java、C#をサポート 現時点ではNode.jsがおすすめ TypeScriptやFlowなど、静的型チェックが可能 JavaやC#はVM起動時のオーバヘッドが存在 公式ライブラリやサンプルが一番充実しているような気がする 参考: AWS Lambdaの処理性能を言語毎に測ってみた
  19. 19. 展開/パッケージ化 Serverless Framework インフラの構築、コードのパッケージ化、デプロイを行うオー プンソースのCLIツール AWS Lambda, Microsoft Azure, Google Cloud Platform、 IBM OpenWhiskに対応 構成を serverless.yml というYAML形式のファイルで定義 AWSに関しては新機能の取り込みは早い プラグイン形式で機能拡張が可能 AWS SAM AWS公式のCLIツール CloudFormationのテンプレートを用いて展開 zipファイルの生成などは手動
  20. 20. AWSに存在するいくつかの制約 AWS Lambda 関数名は64文字まで Serverlessは ${service-name}-${stage}-${function- name} という関数の命名をするため注意が必要 CloudFormation リソースの最大数は200まで それなりの規模のAPIバックエンドの場合、サービスを分割し なければいけない API Gateway 複数のAPIをカスタムドメインにマッピングする場合、一意の ベースパスが必要 CloudFormationの制約でサービスを分割する際は、そのこと に留意
  21. 21. バージョン管理 Serverlessを利用しているのであれば、構成も含めてバージョン管 理できる Lambda関数自体にもバージョン管理の機能がある Serverlessはデフォルトでオン デプロイごとにバージョン番号が振られる リージョンごとにデプロイパッケージの合計サイズが 75GBの制限があり バージョン管理ツールで管理しているのならオフでいいかも 複数の関数にまたがるアトミックなデプロイ、ロールバックの機能 はない 稼働中のサービスに対する大規模なデプロイの際は注意 2系統用意し、API Gatewayのカスタムドメインで呼び出し先 を切り替えるブルーグリーン・デプロイとか
  22. 22. 環境変数 Lambdaのコンソールで環境変数を追加・設定が可能 Serverlessの管理ファイルからもキーバリューの組み合わせを設定 できる コードからは process.env.{KEY} でアクセス センシティブなデータはKMSで暗号化を 参考: KMSで認証情報を暗号化しLambda実行時に復号化する
  23. 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. 24. フレームワーク
  25. 25. いわゆるWebフレームワークはない  http.request や http.response を扱うわけではないので、既存 のフレームワークは使えない ExpressなんかをLambda上でで動かすことはできるけれども、オ ーバーヘッドが大きい
  26. 26. なければ自分で作ればいいのよ!
  27. 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. 28. lambda‑utilities AKIRA‑MIYAKE/node‑lambda‑utilities Lambda関数を開発する際に汎用的に使うことのできる型定義 テストのためのユーティティ関数
  29. 29. serverless‑import‑swagger AKIRA‑MIYAKE/serverless‑import‑swagger SwaggerのAPI定義をserverless.ymlにインポートするCLIツール Swagger Codegenが生成したクライアントのモデルを、Lambda 側のAPIレスポンスの静的な型付けチェックに利用
  30. 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. 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. 32. テスト テストランナーにはMochaを利用 設定が簡単 ブラウザで実行する必要がないため アサーションライブラリはお好みで
  33. 33. テストをしやすくするために 外部リソースに依存する箇所は切り出す Stubに置き換えてテストできるように 依存性は注入できるように テスト時はStubを注入 自分は外部リソースにアクセスするクライアントをまとめたオ ブジェクトを、引数で明示的に渡すスタイルをとっている デプロイして動かしてみるという割り切りも必要
  34. 34. ロギング Lambda関数は異常終了した際はエラーログを出力しない コンテナ自体が落ちるため 失敗する可能性のある処理のエラーハンドリングは確実に 未定義の変数へのアクセスなどを、静的にチェックできる TypeScriptの恩恵が大きい ログ出力用の関数をあらかじめ用意し、それをインポートして使う  process.env.ENV などと組み合わせて、ログレベルはその関 数で制御
  35. 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. 36. まとめ
  37. 37. アプリケーションのちょっとした処理なら非常に有効 イベントドリブンの非同期な処理とか データ更新などをトリガにする処理を疎結合にできるのは魅力 全面的に採用するは今現在では覚悟が必要 フレームワークを自分で作れるレベルの人が、コアを作り込む 必要がある 得られるメリットも大きい 高い可用性と耐障害性 関数単位でデプロイを行えることによるアジリティの向上 関数単位でリソース割り当てを設定できることによる、コ スト最適化
  38. 38. Thank you for listening!

×