[セッションレポート]AWS under the hood 〜AWSを中で支えるサービス群について語る〜 #jawsdays2022 #jawsdays #jawsug

2022.10.25

みなさん、こんにちは。

AWS事業本部コンサルティング部@東京オフィスの芦沢(@ashi_ssan)です。

今回は2022年10月8日に開催されたJAWS-DAYS 2022 - Satellitesのセッションレポートを行います。

AWS under the hood 〜AWSを中で支えるサービス群について語る〜

セッション概要

概要

クラウドコンピューティングは、 2006年3月に誕生しお客様のフィードバックをもとに成長してきました。 このセッションではクラウドコンピューティングの中でもエンジニアの皆さんに大人気のサーバレスコンピューティング基盤を例により、 AWSの哲学に基づきどのように基盤が進化してきたか?をご紹介させていただきます。 また昨今のDiversityが重視される世の中において、クラウドコンピューティングと多様化の親和性や、細分化し続けるユーザーの購買行動との付き合い方などについてご紹介します。

登壇者

亀田 治伸さん

AWSJ エバンジェリスト5号機。実は一番長持ち

動画

レポート

導入

  • AWSの中身の話をしながら、Amazonカルチャーを伝えるセッション!
  • Diversity
    • 企業が女性の社会進出を積極的に支援する
      • これは合ってる?違う?
    • 本来はもっと生々しい話
      • より良い労働環境を整備して、皆に楽しく働いてもらう
      • 綺麗事ではなく、企業の生存戦略
  • Amazonが考えるDiversity
    • 世界中のすべての人に物を売りたい = 世界中のすべての人を理解したい
    • AmazonにとってDiversityは当たり前の考え方
      • とはいえ世界中に人間に合わせるのは難しいため、カテゴライズする(男性、独身など)
  • データ爆発(Data Explosion)が発生し、徐々にカテゴライズが困難になっている
    • SNSによって人格を使い分けることができるようになった
      • 企業は1人の人間を複数の人格として分割して管理できる
    • ユーザーの思考が細分化
      • 企業がビジネスのターゲット層が正しいか?を再定義する必要がある
      • 適切なユーザーに適切なメッセージを送ることが必要とされている
  • 例)ECサイトのヘッドレスコマース
    • マイクロサービスがどのように役に立つのか?は議論されているが、全ての物事を解決するわけではない
    • 例えばDBのセキュリティを中心に考える
      • ECサイトのDBは個人情報の塊(名前、メールアドレス、クレカ情報)
      • このような例でチーム毎にDBを持つことが許容できるか?場合によっては無理
    • このような議論から生まれたさまざまな考え方
      • 分散モノリス
        • 重要なDBは1つだけ、配下にチーム毎のマテリアルビュー
      • モジュラーモノリス
        • アプリの開発はチーム毎に自由、最終的な連結は統一しデプロイは一括
    • エンジニアチームのあり方も変わった
      • 従来のIT企業の枠組みでは対応できない
        • 従来)テクノロジースタックごとに1つのチームに固める
          • ネットワーク、DBの勉強にお金がかかっていた
        • クラウド)多様性を持ったメンバーを1つのチームに固める
          • ネットワークやDBなどの学習コストが下がったことで可能に
        • You Build, You Run it.
          • 「開発した人がそのまま運用する」という当たり前の考え方
      • 今日までにAWSは多くのコンピュート環境を抽象化し使いやすくした

AWSはLambdaをどう改善していったか?

  • 2014年にリリース
  • イベント駆動アーキテクチャ
  • Lambdaのライフサイクル
    • イベント駆動でマイクロVMが起動し、アプリケーションが実行される
    • アプリの実行後はマイクロVMは廃棄される
    • →コンピュートリソースが無駄にならない
  • リリース当初はLambdaの重要性に気づいている人は少なかった(AWS内部でも外部でも
  • 発表当初の対応サービス
    • S3,Kinesis,DynamoDB
  • 制約も多かった
    • 最大1GBメモリ,256スレッド,最大実行時間25,同時実行数25
    • API Gateway,EventBridge非対応
    • VPCアクセスなし
    • 抱えていた課題 = コールドスタートが重い
      • 実行後のマイクロVMが残っている”しばらくの間”は処理が早いが、廃棄された後は数百msec単位の待ち時間が発生
  • その後改善された!
  • 初期のLambda
    • 起動後、裏側で専用EC2インスタンスが作成されていた(AWSは顧客に費用は請求しない)
    • 裏側に問題があったとしたらAWSは改善していく
  • 改善のためにリリースされたもの
    • Nitro System
      • ハードウェアベースのHypervisorで高いセキュリティを確保
      • ゲストOSが外と通信する場合にホストOSのリソースを使用する
    • Firecracker
      • Fargateでも使用されているFramework
      • 単一なハードウェアの上で大量のMicro VMを高速に安全に起動する
  • 1つのベアメタルインスタンスの上に複数AWSアカウントの環境を起動できるようになった
    • 結果として、コールドスタートの問題が改善した
  • もう1つ改善したもの = VPC / Databaseアクセス
    • RDBは常にVPCの中にある
      • 外からアクセスするためには?
    • そもそもLambdaの実態はどこにあるのか?
      • リージョンの何処か → Yes
      • AZの何処か → Yes and No, しかし単一のAZではない
      • 正解は、Lambdaは自前のVPC(サービスVPC)を持っている
      • コールドスタートの場合、動的にENIを作成していたために数十秒かかっていた(最大50秒くらい)
  • VPCシェアリング
    • VPC共有を実装している内部構造 = Hyperplane
    • Hyperplaneによってネットワークオブジェクトを”もう一度”仮想化させた
      • EC2は仮想化されているがハードウェアの上にある、そのため1つのAZに紐ついている
    • LambdaのVPCアクセス環境を作成したタイミングでHyperplaneが仮想化されたENIを作成する
      • 昔はLambda関数が起動するタイミングでENIが動的に作成されていた
    • HyperplaneがENIを作成(数週間くらいのKeepAlive)、コールドスタートが起きにくくなった
  • V2N(VPC to VPC NAT)
    • Hyperplaneで仮想化されたENIを動的にユーザーのVPC内のENIに関連付けする
    • セキュリティグループはHyperplane側のENIにあるため、高速なVPCアクセスを実現
  • Lambdaの起動タイプ
    • 同期型:API Gatewayから呼ばれた時
      • フロントエンドがVMへ通信をルーティング
    • 非同期型:S3へのObjectのPut
      • フロントエンドが通信を内部キューにルーティングし、VMへ到達
    • イベントソースマッピング型:Kinesis
      • フロントエンドの前段にイベントソースマッピングが配置
  • AWSでのコンピューティングは多くの選択肢が増えたために、学習難易度は上がっている
  • 今年のre:Invent2022でも「何か」が出る!?!?!?

学びの方程式

  • 興味 x 義務 x 情熱 = 結果
    • 興味: 決めた時間はやってみる
      • 5時間やってみて、合わなかったらやめる
    • 義務: アウトプットを最初に宣言する
      • LTに出ます!などを宣言
    • 情熱: 楽しそうな人に交わる
      • コミュニティ参加で周りから刺激を受ける

まとめ

AmazonカルチャーとしてのDiversityへの向き合い方、なぜサービスを改善し続けるのか、そこからAWSによるLambdaの改善史へと展開してゆくセッションでした。

リアルタイムでは聞くのがしていた箇所が多かったため、最近Youtubeチャンネルに上がったアーカイブ動画を見て補完しましたが、2回登壇を聞くことができて理解度がより深まりました。

結びの学びの方程式で一気に心が持っていかれた方、多かったのではないでしょうか?私もその1人です。

このエントリを見ているそこのあなたも、ぜひYoutubeのアーカイブ動画を見て当時の熱狂を追体験してみてください!

以上、AWS事業本部コンサルティング部@東京オフィスの芦沢(@ashi_ssan)でした。