Serverless BEAM with FaaS 2019/06/01 Erlang & Elixir Fest 2019 おーはら@tokyo.ex

agenda ● about me ● goal ● サーバーレスアーキテクチャの進化と歴史 ● サーバーレスアーキテクチャの長所と短所 ● Elixirをサーバーレスアーキテクチャ環境で動かす方法 ● サーバーレスElixirアプリの運用 ● サーバーレスElixirに足りないもの ● まとめ

about me ● Tsunenori Ohara/おーはら ○ Twitter: @ohrdev ○ Github: ohr486 ● Work ○ (株)ドリコム HTML5ゲームプラットフォームの開発 ○ CTO室 ○ インフラ/基盤/アーキテクチャ設計 ,Elixir/Erlang/HCL/SL/Ruby/Golang ● Community ○ tokyo.ex, ElixirConfJapan, Erlang&ElixirFest オーガナイザー ○ Japan Elixir Association ○ meguro.rb, meguro.es ● Hobby ○ 仏像制作, 丸太収集, 写経, 寺社仏閣 ○ 人工衛星/アマチュア無線

goal ● サーバーレスアーキテクチャの概要を理解する ● AWS Lambdaの概要を理解する ● Elixirをサーバーレスアーキテクチャで動かす方法を知る ● サーバーレスElixirの運用方法を知る ● サーバーレスElixirを動かす方法を知る

サーバーレスアーキテクチャの進化と歴史 ● 簡単に言うと、以下のようなアーキテクチャ ○ 「サーバーを自前運用せずに、マネージドサービスの組み合わせで構築する」 ○ 「リクエスト単位で必要な CPUリソースをリアルタイムで確保し処理できる」 ● よく利用されるマネージドサービスは以下 ○ AWS Lambda, API Gateway (AWS) ○ Cloud Function (GCP) ○ Azure Function (Azure) ● 何が嬉しいのか？ ○ スケールを意識しなくてよい（勝手にスケールイン・アウトしてくれる） ○ 費用が安い（使ったぶんだけ費用を払えば良い）

サーバーレスアーキテクチャの進化と歴史 ● サーバー運用のトレンド ○ 物理サーバーによる運用 : オンプレ ○ 仮想VMによる運用 : ex) VMware, etc ○ クラウドによる運用 : ex) AWS EC2, etc ○ コンテナによる運用 : ex) Docker, Kubernetes いまは、ここから ○ マネージドなコンテナサービス : ex) AWS ECS, GKE, EKS このあたりまで ○ Function as a Service : ex) AWS Lambda, Cloud Function, Azure Function これからは ● Webサービスのアーキテクチャの文脈で語られる事が多い

サーバーレスアーキテクチャの長所と短所 ● 長所 ○ サーバー運用費用が安い ■ リクエストレベルで必要な分だけ費用が発生する ○ 運用オペレーションが不要 ○ 自動でスケールしてくれるのでトラフィックスパイクに強い ● 短所 ○ デプロイメントが複雑 ■ ex. ローカル開発, テスト, 動作環境 ○ 対応したライブラリが少ない ■ ex. フレームワーク ○ データベースに制約がある ■ ex. ハイトラフィック時のコネクション数の上限など ○ 様々な制約 ■ ex. 関数の同時実行数, 関数の最大処理時間 /タイムアウト時間

サーバーレスアーキテクチャの長所と短所 ● サーバー費用の月額比較(APIサーバーのcompute部分) ○ 一般的なAPIサーバー ■ 30日 x 24時間 x 1時間あたりの価格 ○ サーバーレス ■ リクエスト数 x リクエストあたりの平均処理時間と必要メモリの価格

サーバーレスアーキテクチャの長所と短所

サーバーレスアーキテクチャの長所と短所

サーバーレスアーキテクチャの長所と短所 ● サーバー費用の月額比較(APIサーバーのcompute部分) ○ 一般的なAPIサーバー ■ 30日 x 24時間 x 1時間あたりの価格 x 台数 ○ サーバーレス ■ リクエスト数 x リクエストあたりの平均処理時間と必要メモリの価格 ○ 一般的に数倍〜、サーバーレスのほうが安く てすむ ● compute以外の部分は共通 ○ データベス ○ ストレージ ○ 監視 ○ etc

demo0 費用計算ツールによる費用試算

Elixirをサーバーレスアーキテクチャで動かす方法 ● カスタムランタイムを利用 ○ AWS Lambdaで任意の言語ランタイムを実行させる機能 ○ 実行環境はAmazon Linux、利用できる環境変数は以下 ■ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/current-supported-versions.html ○ 必要なもの ■ bootstrap : Lambda起動時に実行されるファイル ■ function handler : 関数呼び出し時に実行するハンドラ ○ 内部的にはAWS Lambdaランタイムインターフェース (HTTP API)をcall ■ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-api.html ○ パッケージングについては割愛、以下のドキュメントをご参照ください ■ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtimes-walkthrough.html

Elixirをサーバーレスアーキテクチャで動かす方法 ● 今まででAWS Lambdaのアーキテクチャの情報はあまりなかったが、 re:Invent2018でアーキテクチャ詳細の発表があった。詳しくは以下を参照 ○ https://www.youtube.com/watch?v=QdzV04T_kec&feature=youtu.be ○ https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the- hood-srv409r1-aws-reinvent-2018 ● 内部的にはFirecrackerが基盤となっている ○ https://firecracker-microvm.github.io/ ■ 超軽量VM(microVM)をセキュア・高速・大量に起動できるコンテナマシン ■ KVM上で動作、Rust実装、OSS

Elixirをサーバーレスアーキテクチャで動かす方法

webサービス Elixirをサーバーレスアーキテクチャで動かす方法 ● Elixirとサーバーレスアーキテクチャの関係性 inet cloud Reqイベント リソース確保 イベント毎の計算 Resp返却 リソース解放 Respデータ request response ・マネージドサービスで構築 ・自動でスケールイン・アウト

webサービス Elixirをサーバーレスアーキテクチャで動かす方法 ● Elixirとサーバーレスアーキテクチャの関係性 inet cloud Reqイベント リソース確保 イベント毎の計算 Resp返却 リソース解放 Respデータ request response API G/W ALB AWS Lambda Custom Runtime

Elixirをサーバーレスアーキテクチャで動かす方法 ● ランタイムインターフェース ○ 次の呼び出し ■ GET: /runtime/invocation/next ■ 呼び出しイベントを取得する ○ 呼び出しレスポンス ■ POST: /runtime/invocation/{REQ-ID}/response ■ 呼び出しレスポンスを Lambdaに送信する、Lambdaはそのレスポンスをクライアントに送信 する

Elixirをサーバーレスアーキテクチャで動かす方法 Runtime API bootstrap λ start /invocation/next runtimeの初期化処理 request handler {payload} /invocation/{req-id}/response /invocation/next response start

Runtime API bootstrap /invocation/next runtimeの初期化処理 request handler {payload} /invocation/{req-id}/response /invocation/next response init phase invoke cycle start λ start Elixirをサーバーレスアーキテクチャで動かす方法

Runtime API bootstrap /invocation/next runtimeの初期化処理 request handler {payload} /invocation/{req-id}/response /invocation/next response init phase invoke cycle 呼び出しイベント取得 呼び出しレスポンスを Lambdaに送信 start λ start Elixirをサーバーレスアーキテクチャで動かす方法

demo1 hello world webアプリ

サーバーレスElixirアプリの運用 ● 運用に必要な要素 ○ アーキテクチャ上の制約 ○ 監視 ○ デプロイメント

サーバーレスElixirアプリの運用 ● アーキテクチャ上の制約 ○ データベース ■ リレーショナルデータベース /NoSQLデータベース ● 同時接続数・コネクション数に上限がある ● ハイトラフィック時に接続数が上限を越えるとダウンする ● コネクションの同時接続数管理やプーリングの機構が必要 ■ クラウドベースのデータベース ( DynamoDBなど ) ● HTTP通信ベースが一般的に多い ● ハイトラフィック時も性能劣化することなく利用できる ■ 一般的にクラウドベースのデータベースを利用することが推奨される

確保されたリソース (コンテナ) 確保されたリソース (コンテナ) サーバーレスElixirアプリの運用 ● サーバーレスアーキテクチャのデータベースコネクション request 確保されたリソース (コンテナ) DB DB con scale スケールすればするほど、コ ネクション数が増える 扱えるDBコネクション の上限がある MySQL, Redis, etc リクエストが増えるとスケール する

確保されたリソース (コンテナ) 確保されたリソース (コンテナ) サーバーレスElixirアプリの運用 ● サーバーレスアーキテクチャのデータベースコネクション request 確保されたリソース (コンテナ) cloud DB (DynamoDB) http scale スケールすればするほど、リク エスト数が増える リクエスト数が増え ても問題ない リクエストが増えるとスケール する 推奨

サーバーレスElixirアプリの運用 ● 監視 ○ マネージドな監視サービス /SaaS ■ CloudWatch : AWS Lambda, API Gateway, database ■ x-ray: 分散トレーシング ■ newrelic : AWS Lambda ○ cloudwatch ■ https://aws.amazon.com/jp/cloudwatch/ ○ x-ray ■ https://aws.amazon.com/jp/xray/

サーバーレスElixirアプリの運用 ● デプロイメント ○ 関数/API単位でデプロイメント ■ 複数の関数でアプリが構成されるので、関数単位ではなく関連群単位でデプロイする ■ AWS Lambda ■ API Gateway ○ マネージドなデプロイサービスやツールが (大抵のクラウドには)存在する ■ CloudFormation ● https://aws.amazon.com/jp/cloudformation/ ■ serverlessframework ● https://serverless.com/

demo2 監視

サーバーレスElixirアプリの運用 ● デプロイメントに利用するツール ○ docker ■ AWS Lambda上での動作環境に合わせたラインタイムビルド ○ distillery ■ https://github.com/bitwalker/distillery ■ リリースマネージャ ■ リリース: コンパイルされたElixirのバイナリ/ランタイム、起動scriptなどを含むパッケージ ○ cloudformation ■ https://aws.amazon.com/jp/cloudformation/ ■ AWS Lambdaの適用

サーバーレスElixirアプリの運用 ● デプロイメントの内部構造 ○ AWS Lambda はAmazon Linuxのコンテナとして動作 ■ 環境情報は https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html 参照 ○ 同環境のコンテナ内で、 Elixirアプリをランタイムと一緒にパッケージング ○ AWS Lambdaのコンテナで動作するパッケージを cloudformationでdeploy

AWS サーバーレスElixirアプリの運用 AWS Lambdaの実行環境 コンテナ Amazon Linux docker image ex) https://hub.docker.com/r/lambci/lambci local / build PC docker release package release build AWS Lambda Func Amazon Linux Image = Lambda実行時と同環境 同一 Lambdaの実行時の環境で 動作するバイナリ CloudFormation 起動 req res distillery pkg

AWS サーバーレスElixirアプリの運用 [init phase] step1. bootstrapを実行 step2. Erlang RTSが起動 step3. リクエストを処理する handlerアプ リが起動 step4. /invocation/next をcallしてリクエ ストを取得開始 release package AWS Lambda Func /bootstrap ... bin以下の起動scriptを叩いてアプリ起動 /bin/ ... 実行ファイル、起動scriptなど /lib/ ... 関連ライブラリ群 /releases/ … リリース関連

サーバーレスElixirアプリの運用 Runtime API λ start /invocation/next elixir handler Erlang RTS start OTP App start elixir lambda core start bootstrap start OTP App

AWS サーバーレスElixirアプリの運用 [invoke cycle] step5. reqを受付たデータでhandlerをcall step6. (Elixirで実装された)handlerが実行されresponseを作成 step7. /invocation/{REQ-ID}/responseをcallしてlambdaにresponse を送信 step8. lambdaがクライアントにresを返す step9. /invocation/nextをcallして、次のreqを受付開始 step10. step5.に戻る req res コンテナがshutdown 新しいコンテナがup

サーバーレスElixirアプリの運用 Runtime API request /invocation/next elixir handler Erlang RTS {payload} elixir lambda core bootstrap :ok | {:ok, result} handle(Event, Context) /invocation/{req-id}/response response

サーバーレスElixirアプリの運用 Runtime API elixir handler Erlang RTS elixir lambda core bootstrap AWS Lambdaのカスタムランタイム Elixir/ErlangのRTS AWS Lambdaを扱うコアライブラリ Elixir実装の ハンドラ

not DEMO (時間がないので、紹介のみ) [erllambda: AWS lambda in Erlang] https://github.com/alertlogic/erllambda_elixir_example ※本資料で解説したアーキテクチャはこちらのrepoがベースとなっています

demo3 デプロイメント

サーバーレスElixirに足りないもの ● クラウド側の対応（AWS, GCP, Azure, etc） ○ 現状、AWS Lambdaが一番環境が整っている（個人的な主観 ● WAF（Web App Framework） ○ AWS Lambda Custum Runtime発表以降ちょくちょく作成され始めている ○ ex) Ruby: Jets https://rubyonjets.com/ ● deploymentツール ○ cloudformation ○ serverlessframework ○ SAML ○ etc

まとめ ● サーバーレスアーキテクチャの概要を紹介しました ● Elixirをカスタムランタイムを使って動作させた場合の概要を紹介しました ● サーバーレスElixirのデプロイメントの概要を紹介しました ● 現在は研究段階のフェーズで、まだ本番投入までには至っていません ● サーバーレスElixirの領域は、まだまだ未成熟な領域なので、貢献できる箇所がた くさんあります ● Let’s be serverless!

宣伝 非公式後夜祭やります@ドリコムオフィス japan.ex #1 : https://beam-lang.connpass.com/event/130690/