日比谷のクラスメソッド社さん会場に100名以上が集結するオフラインイベント、午後編です！

※リアルタイムの走り書きのため、誤り等あればお知らせください🙏

前編はこちら👇

Refactoring Serverless / 淡路大輔 (AWS)

SA淡路さんのセッション。短時間ですが非常に情報量が多く、「アーキテクチャ道場！」を彷彿とさせる濃密でエキサイティングなセッションでした🔥

Lambdaだけじゃない！周辺のAWSサービスに処理が委譲されてきた。
AWSサーバーレスの歴史
- Lambda, API Gateway, Step Functions, SQS, SFn Express Workflows/SDK Integration
サーバーレスアプリ設計のアプローチ
- イベント： DynamoDB, S3, API Gateway
- Lambdaファンクション →もしこのGlue（のり付け）が不要になったら？
- 連携先サービス: DynamoDB, S3, SQS
従来は
- Lambdaでサービス間の連結処理を実施していた
- 今はLambdaなしでもサービス間を繋げるようになってきている
リファクタリングとは：「外部の動作を変更せずに」作り替えること
- 参考 https://serverlessland.com/testing/patterns

リファクタリングパターンの例

① メッセージ送信（Lambda）
- Lambda Destinatinoを使えばコード内に依存関係を埋め込まなくて良くなる
- CDKコードにトポロジーが集約できる
- エラーハンドリング：コードでtry/catchを書かなくてもCDKでonSuccess/onFailureを書ける
- 注意点：非同期Lambda呼び出しのみサポート。SQSへの送信はFunctionの最後になる
- サーバーレスをリファクタリングする目的とは？
  - マネージドサービスのフル活用
  - AWS新機能の取り込み
  - アプリケーションの要件追加
  - ランタイムの特性改善
  - コスト削減
② サービス統合（Step Functions）
- サービス統合を使えば、Lambdaを咬まさずに他サービスを呼び出せる
- メリット：コスト、複雑性、制約（実行時間など）を緩和できる
- 例：
  - Before: CDKでSFnワークフローを書き、GlueコードとしてのLambdaを利用（トポロジーがコード内に埋没）
  - After: CDKで他サービス呼び出しをまとめられる
③ メッセージ送信（EvB Pipes）
- Before
  - Lambda → DynamoDBのトポロジーが環境変数に埋没
  - その後、EvBを呼ぶトランザクションが別になってしまう
- After
  - DynamoDBを呼んだトランザクションのまま、後段のEvBを呼べる
- メリット
  - ビジネスロジックが分かりやすい
  - 接続構成（トポロジー）が分かりやすい
  - トランザクションの整合性が保てる
  - DynamoDB Streamによる重複排除が可能

Lambda関数のロジック粒度を考える

Lambda-lith: APIGW -> Lambda -> DynamoDB
Nano Lambda: パス（作成/更新/削除）ごとにAPIとして関数を分ける
- アプリ全体の構成が分かりづらい。改修箇所の特定が困難
APIGW to SFn
- SFn Express WorkflowをREST APIに活用する
- ロジック可視化、Lambda削減、コスト効率化
- 事例：Serverlesspresso（EDAなコーヒー注文アプリ）

まとめ

単なる「Glueコード」としてのLambdaをやめよう
CDKのような自動化コードで接続構成を見やすくしよう
粒度を見直そう。Nano Lambdaが正解とは限らない。Lambda-lithも悪とは限らない

LLM 時代におさえておきたい Azure Serverless ファミリーまとめ / Kazuyuki Miyake (ZEN Architects)

Microsoft MVPの三宅さんです。

LLM on Azure

LLM時代の到来で変わったこと
- とりあえず早く試したいニーズ
- OpenAIでAzure利用者が増えた
OpenAIでAzureを使う理由って？
- AOAIは本家OpenAIと全く一緒、価格も同じ
- プライベートネットワーク
- 東日本リージョンでトラフィックが完結する -> これはAzure随一！
- AzureのSLAやサポートが適用される

Copilot Stackをサーバーレスで構築する

Copilot Stackとは？
- アプリとLLMの間にオーケストレーション層を挟むアーキテクチャ

オーケストレーター層
- Container AppsやFunctionsを利用する
- LangChainやSemantic Kernelが使える
チャットUI層
- LINEなど既存のものを使えるとラクだが…
- ウェブ画面を作る場合、これまではApp Serviceが中心だった
  - 静的ホスティングならStatic Web Appsで十分！コストも安くなる
  - Next.js / Nuxtなど主要なFWに対応
- Easy Authを使うと認証の追加も簡単
チャット履歴
- LLMとのやり取りがステートフルにできる！
- CosmosDBが相性バッチリ。JSONそのまま投げられて、スケーラブル
  - 実はChatGPTのバックエンドもCosmosDBが使われている
  - LangChainのMemoryに簡単に組み込める
RAGパターン
- ChatGPTと比べた場合の大きなメリット！
- 最近の案件ニーズは大体これ
- Cognitive Search
  - ElasticSearchベースの検索エンジン
  - ベクトル検索にもプレビュー対応
  - キーワードとベクターのハイブリッド検索ができる
セキュアな構成
- マネージドIDでAPI認証
- サービスエンドポイント＆VNet統合でネットワーク制御

Azure OpenAI Service リファレンスアーキテクチャからみる、本番システムレベルのLLMアプリに必要な検討項目の解説 / 坂部広大 (Microsoft)

AzureのSA坂部さんのセッションです。

キャッチアップ

一般的なウェブアプリの場合（App Service + DBの接続）
- コンテナの場合：App Service (Web App for Containers)
- 非コンテナの場合：App Service (Web Apps)
ネットワーク接続に複数の方法がある
- 通信方向によって必要となるAzureサービスが異なる
- プライベートエンドポイント
  - プライベートリンクへ接続するための追加NICのようなもの
- プライベートリンク
  - プロバイダー側に作成されるサービス
認証（App ServiceとFunctionsの場合）
- 組み込みの認証認可（Easy Auth）：AAD, SNSログイン, OpenIDなどに対応

リファレンスアーキテクチャ

パターンがいくつもあるが、基本的なWebアプリとしての構成は大きく変わらない
現在は大きく3種類
- 価値にウェイトをおくパターン
- 基盤を固めるパターン
- ある特定の課題にフォーカスするパターン
共通すること
- エンドポイントを安全に保護する
- ログを記録する　…等
特徴的な違い＝非機能要件のトレードオフ
- データの特徴、セキュリティ、ネットワーク、データサイズ、品質改善手法
色々なバリエーション
- クエリベースの文書要約
- 中央データの加工・分析
- セキュリティガチガチ

アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化 / Yoshitaka Koitabashi (KDDIアジャイル開発センター株式会社 / Momento - Community Advocate)

我らがKAGの小板橋さん @yoshii0110 から、すべてのエンタープライズ企業に捧げるセッションです！

KAGとは？

もともと2013年ごろからKDDI内でアジャイル開発を推進していた一部署だった

社内事例：アーキテクチャの変遷

2014年：契約一元管理システム
- 国産クラウド（cloudstackを採用）でVM稼働
- 24/365で開発運用していた
KDDI CCoEチームが社内にAWSを開放！
2016〜2018年
- よくあるフロントエンドやWeb API構成
- Home IoT基盤の例：Lambda, DynamoDBなどのサーバーレスを活用（うまくVPCを併用）
- 監視基盤の例：ログを集約しKinesis Data Stream経由でLamda -> Datadogに連携
2020年〜
- 教育系サービス基盤の例：より複雑なサーバーレス構成が可能になった
  - 接続先のシステムによってPrivateLink等を使いつつも、イベント駆動アーキテクチャを活用
- CI/CD：CircleCI, Yamoryなど外部サービスを組み入れて活用
- 開発の各工程で様々な技術スタックが増え、社内エンジニアのナレッジが広がってくる
2021年〜
- MaaSシステムの事例：データストアがNeptune、それ以外はほぼ全てサーバーレス
  - データ分析にGlue -> SFn -> Google Cloudに流して分析
- デプロイも変化。GHA経由でServerless Flamework利用など
- KDDI Engineer Portal（自社ブログ）
  - https://developers.kddi.com/
  - App Runnerを活用
- タビトシゴト
  - https://tabitoshigoto.com/
  - Amplify, Strapi等を活用して3ヶ月でスピード構築（うち実作業は1ヶ月程度）

これからのアジャイル開発、サーバーレス活用

どういったサービスが適切か？
- アジャイル＝顧客の価値を中心におく。
- 本当に必要なニーズを押さえているサービスを選定する
アジャイル開発の手法
- スクラム、XP、カンバンを使い顧客が欲しいものをスピーディに開発
- 価値選択、開発、振り返りのサイクル（スプリント）を一定周期で繰り返す
ソフトウェア工学の観点で見ると…
- 「効率的」で「経済的」であることを目指すなら、学びの能力を持続せねばならない
- そのためには、今作っているシステムの複雑さを管理しなければならない
- 船を作るのとソフトウェアを作るのは違う！
  - ソフトウェアは「イテレーション」ができる
サーバーレス、アジャイルのつらみ
- 顧客の真のニーズを満たすにはイテレーションを繰り返す必要がある
- しかし価値に直結しない様々なタスクによって阻害されてしまう
ソフトウェア開発の知見をチームが正しく理解していれば、不要なタスクを削減できる
- これからは1つのクラウドサービスで完結させる必要はない。様々なSaaS, PaaSを組み合わせればよい
- サーバーレスを組み合わせれば「インフラのコード化」すら必要なくなる
自由な技術から最適な選択肢をとれることが重要！

10yrs lessons for Serverless practices and how to build LLM app using SST for startups / Peter Sbarski (AWS Serverless Hero)

元ACloudGuru VP / Serverlessconf Chiefのピーターさんのセッション！

Amazon Prime Videoの脱サーバーレス化の話

Prime Videoシステムの基本機能
- 変換・分析・転送
アーキテクチャ
- Before: Lambda, SFn, EC2, S3, SNS, Mediaサービス等で構成
- After: ECSベースの構成に変更
  - EC2データプレーンにはSavings Plansを活用
分散処理へ
- ビデオを分割 -> 変換 -> 結合
- Lambdaで処理するのが一番早くエンコードできた

そして本題

今日のアプローチ
- サーバーレスによって技術的な判断を素早くしたい
- AWSや多数の3rdサービスを利用したい
- UXで差別化したい
AWSのサーバーレスのコアサービス
- Lambda, SFn, APIGW, DynamoDB, EvB, S3
SST (Serverless Stack)
- モック不要、ローカルからAWSサービスへプロキシしてくれるのでテストしやすい
AIはUXを飛躍的に押し上げる
- Microsoft GuidanceとLangChainの比較
- Amazon Bedrockの登場（まだ限定プレビュー中なので詳細は話せませんが…）
モダンアプリケーション
- セキュリティ/コンプラ優先、マイクロサービス、なるべくサーバーレス、CI/CD、とにかく監視…
- サーバーレスモノリスもアリ、自動化はマスト、サーバーレスでどんどん実験

サーバーレスな開発ライフサイクルのモメンタムの変遷＋秋のサーバーレス運動会 / Harunobu Kameda (Cloudflare)

Cloudflareについて

世界のインターネットトラフィックの25%を支えている
- ユーザーの95%が50ms圏内
サーバーレス環境：Developer Platform
- Compute
  - Workers: AWS Lambdaに近いが少し違う特徴を持つ
- Storage
- Network
- Developer Experience

Cloudflare Workers

CLoudflareにはリージョンがなく、デプロイすると全世界に展開される
Lambdaとの違い
- リージョン、VPCがない
- Service Workers + Web WorkersベースでJSを実行する
  - Node.jsサポートが限定的（JSをサーバーサイドで動かせるため）
  - LambdaというよりもCloudFront Functionsに近い
イベントトリガー
- HTTP/フェッチ、Cron、キュー、アラーム、Eメール
最近のアップデート
- Workers Connect：OutboundのTCPソケット通信に対応（これまではHTTPのみ）
  - 主にDB通信での利用を想定
- Workers Smart Replacement：ユーザーよりもDBに近いWorkersを使ってくれる
秋のServerless運動会
- 速かった順：Rust(WASM) Workers, Node.js Lambda@Edge（コールドスタート無し）, JS Workers

Storageオプションの紹介

結果整合性を意識して使い分ける必要あり

Workers + Pages

Pages Functions：SSRを実現できる
ちなみにWorkersがNode.jsじゃないのにNext.jsが動く理由：Edge Runtime
- 個人的にはNext.js使うならVercelを推奨

なぜサーバーレスがエッジに登場してきたか？

出てきたばかりなのでシンプルなサーバーレスから始まっている？
- You Build It, You Run It
- AWS Lambdaの裏側は昔コンテナ、今マイクロVM
- DBへのアクセス：VPC内にある
  - VPC Sharingの登場でNWコンポーネントが高度に仮想化。アクセスが速くなった
- 呼び出し方：同期、非同期、イベントトリガー
CDNの進化？
- Web高速化ツール -> プログラム実行基盤へ
- 仮説：高速化よりもセキュリティへのニーズが高まっている？
- SSL/TLS脆弱性の歴史（大変だった…）
- CDNはセキュリティの専門家が面倒を見てくれているため、プロキシ層でセキュリティ対策ができる
通信プロトコルの進化にオリジンが取り残されている？
- IPv6, HTTP3/QUIC
- TCPとUDPの違いをざっくり紹介（通信品質の向上でUDPでもパケット欠落は少なくなった）
  - HTTP2は難しくて普及せず
  - HTTP3/QUICはUDPベースで作り直された
- IPv6移行率 50.9%、HTTP3/QUIC移行率 38.7%
  - モバイルの場合は通信事業者側の対応により普及できる。固定回線が課題
  - IPv6の方が早い：NATの占める割合が多いと考えられる

CLOSING KEYNOTE / Khawaja S Shams (Momento)

元Amazon DynamoDB VPのカワジャさんのクロージングセッション！

コミュニティの力について

本日の運営メンバーへの感謝も

Momentoの紹介

なぜサーバーレスか？
- セキュリティ、可用性、拡張性
インフラを自分で作ると考えることがいっぱい
- エンドユーザーにとって大事なもの：レイテンシー、可用性、キャッシュヒット率
- 裏側の仕組みは直接価値を生まない
Momentoは1日に10億Itemsを捌いている
Momento Topics：Pub/Subサービス
- Amazon SNSと比較してメリットあり。フロントエンドからも直接使える
Momentoの内部構成の紹介
- NLB, ルーティング層, キャッシュノード群
  - ルーティング層とキャッシュノード群が別々にスケールできる
- ルーティング層の重要な役割の紹介
Momentoを使えば自分で組むより構成が大きくシンプルになる
Momento Vector Index
- 利用手順はシンプル：インデックス作成 -> 検索

Serverless Days Tokyo 2023に参加してきました！（後編）