[#ServerlessDays 2019]Keynote: AWS

スライドが投稿され次第､追加と内容の修正を行う予定です｡

セッション概要

• 登壇者: Keisuke Nishitani (AWS)

内容

AWS Lambdaはイベント・ドリブンのサービスとして登場した

2014年にAWS Lambda(以降､Lambda)が登場した時に､まだサーバーレスという概念は無くイベント・ドリブンのサービスとして登場しました｡ イベント・ドリブンとは､状態の変化をきっかけとして処理を実行するアーキテクチャの事です｡
ある動画の変換プロダクトにサービスを追加するというシチュエーションで､イベント・ドリブンか､そうでは無いかで比較をしてみます｡

イベント・ドリブンでない場合

リクエストを受け付けるサービスが存在し､このサービスはそれぞれのサービスへリクエストを分散させます｡各サービスはリクエストを受け取りって処理を開始します｡
新しいサービスを追加する場合は､そのサービスの開発とそれに向けてもリクエストを追加します｡

イベント・ドリブンである場合

リクエストを受け付けるサービスが存在し､このサービスはリクエストをメッセージングに格納します｡各サービスはメッセージングをサブスクライブしており､メッセージを受け取ると処理を開始します｡
新しいサービスを追加する場合は､そのサービス開発(サブスクライブ処理を含む)を行うだけで良いです｡

比較するとイベント・ドリブンである場合は､新しいサービスの追加を行う際に､リクエストを受け付けるサービスに手を加える必要がありません｡ つまり､アーキテクチャが疎結合になっています｡

アプリ開発者の為のサービスリリースとサーバーレスの登場

2015年にAPI Gatewayが登場し､LambdaがAPIリクエストを受け付ける事が可能になりました｡サーバーレスの誕生です｡
これまでは､インフラストラクチャのサービス､つまりインフラエンジニア向けのサービスがほとんどだったが､2014年､2015年はアプリケーションエンジニアの為のサービスが登場し(Lambda､ ECS､ Codeシリーズ)､AWSに関わる人々にとって重要な時期でした｡

VPC Lambdaの改善

全てのLambdaはAWSサービスチームが管理するVPC内に存在し､私達がVPC Lambdaを使う場合は､ネットワークの出口としてENIがユーザーVPC内に1:1で払い出されるだけです｡
今までVPC Lambdaを使う際には､このENI払い出しが原因のいくつかの問題がありました｡

• ENIの作成に10秒〜30秒かかる
  • コールドスタートが遅い
• IPアドレスを消費する
  • ENIの作成=IPアドレスの割り当て
  • Lambdaの種類ではなく実行している数毎に1つENIが必要
• スケーリングに制約がでる
  • 残IPアドレス数=Lambda最大同時実行数となる

AWS HyperplaneというAWS内部サービスによって､LambdaとENIの連携が改善し上記の制約が取り払われました｡ Hyperplaneは他にEFS､NGWやNLBなどネットワークに関するサービスで利用されているようです｡

サービスチームVPC内のLambdaからユーザーVPC内のENIに直接繋がるのではなく､VPC to VPC NATを経由して繋がる事で､Lambda:ENI=N:1となりました｡ これによって､Lambdaを一定数実行しても使用するENIは1つで足りるようになります｡

セッション中に説明はありませんでしたが､この改善に合わせてLambda関数が作成された時点でENIが作成されるようになった為､コールドスタート時にENI作成待ち時間も改善します｡

この改善によって､LambdaからElastiCacheを利用したいシチュエーションでコールドスタートが理由で諦めなくて良くなります｡また､RDSの利用も同様に採用しやすくなりますが､もう1つのネックについての検討は引き続き必要です｡

セッション中に説明はありませんでしたが､このネックというのは恐らくDBコネクション数が枯渇しないか検討が必要という事だと思われます｡

モダンアプリケーションとサーバーレス

ここでのモダンアプリケーションの定義は､以下の通りです｡

• オペレーション
  • 価値を産まない作業をオフロードしすべてを自動化
• アーキテクチャ
  • 極小化されたスコープとマイクロサービス､疎結合でイベント・ドリブン
• Developer Firstな開発フロー
  • すべてを自動化
• セキュリティ
  • 自動化､継続的､適切なアクセス制御
• データ
  • 各コンポーネント毎に適切なデータストアを活用

これに期待される効果として､以下があります｡

• 市場投入が早い
  • 開発サイクルが高速
• イノベーションの向上
  • マイクロサービスで開発する事で､各サービスで積極的にトライできる
• 信頼性の向上
  • 各段階でテストをする
• コスト削減
  • 従量課金の請求

疎結合なアーキテクチャで開発サイクルを高速化し､サービスの価値を素早く改善し続ける為の手段として､モダンアーキテクチャがあります｡

アプリケーションを構築する際に､利用できるAWSのコンピューティングサービスは以下が存在します｡

• Amazon EC2
• Amazon ECS(Fargate), EKS
• AWS Lambda

サーバーレスで構築するならば､AWS Lambdaが該当します｡
また､アプリケーションには､コンピューティング以外に必要な物が色々あります｡

Amazon RDS､Amazon ElastiCacheなどマネージドサービスを利用する事も､Amazon EC2の上に自分で構築する事もできます｡

Lambdaはイベント・ドリブンなサービスなので､モダンアプリケーションを実現するのに適切です｡
他にもステートを持ちたい場合のStep Functions､インテグレーションの為のSNS/SQSなど､AWSには便利なサービスが多く存在します｡

サーバーレスの目指す世界

なぜ､モダンアーキテクチャを使うの､サーバーレスを採用するのか､クラウドを利用するのか､楽をしてその分､プロダクトの付加価値を高めることに注力したいからです｡

｢All you need is code｣､やりたい事をコードで書くだけで良い世界が来る､｢全てがサーバーレスになる｣と思っているが､まだそういった世の中にはなっていません｡

サーバーレスはまだ未完成で､提供元・利用者が一体となって､もっともっと知見を共有する必要があると考えています｡

あとがき

Lambdaの登場や改善の話､なぜモダンアプリケーション､サーバーレスを使うのかっ盛りだくさんで､とても為になるセッションでした!
コードを書くだけで良くなる世界がくるというのは､まさにその通りだと思っており､どんどんオンプレミスからクラウドへ置き換わっているのと同じように､そういう日がいつか来て欲しいです!