日比谷のクラスメソッド社さん会場に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なしでもサービス間を繋げるようになってきている
- リファクタリングとは： 「外部の動作を変更せずに」作り替えること
リファクタリングパターンの例
- ① メッセージ送信（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による重複排除が可能
- Before
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ヶ月程度）
- MaaSシステムの事例：データストアがNeptune、それ以外はほぼ全てサーバーレス
これからのアジャイル開発、サーバーレス活用
- どういったサービスが適切か？
- アジャイル＝顧客の価値を中心におく。
- 本当に必要なニーズを押さえているサービスを選定する
- アジャイル開発の手法
- スクラム、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
- Compute
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を使ってくれる
- Workers Connect：OutboundのTCPソケット通信に対応（これまではHTTPのみ）
- 秋の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, ルーティング層, キャッシュノード群
- ルーティング層とキャッシュノード群が別々にスケールできる
- ルーティング層の重要な役割の紹介
- NLB, ルーティング層, キャッシュノード群
- Momentoを使えば自分で組むより構成が大きくシンプルになる
- Momento Vector Index
- 利用手順はシンプル：インデックス作成 -> 検索