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

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

https://tokyo.serverlessdays.io/

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

### 前編はこちら👇

https://qiita.com/minorun365/items/b03fed43fabc245fad38


# Refactoring Serverless / 淡路大輔 (AWS)

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

![IMG_0032.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/71553c09-d9d2-daca-ab2b-67f799a29669.jpeg)

- 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も悪とは限らない

https://speakerdeck.com/gawa/refactoring-serverless



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

Microsoft MVPの三宅さんです。

![IMG_0034.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/1b858f56-e2a8-efeb-b692-c744a8728f89.jpeg)

### LLM on Azure

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

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

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

![IMG_0035.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/338d742f-770c-4ee9-7603-be5bd6cf1ace.jpeg)

- オーケストレーター層
    - 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統合でネットワーク制御

https://speakerdeck.com/miyake/serverlessdaystokyo2023-llm-aoai



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

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

https://koudaiii.com/

![IMG_0037.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/1d2744b9-7d62-7e7b-6ade-d131334def85.jpeg)

### キャッチアップ

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

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

https://www.microsoft.com/ja-jp/events/azurebase/contents/default.aspx?pg=AzureOAIS

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



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

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

![IMG_0038.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/508c2978-dfe2-516b-99e1-b6a9806b4788.jpeg)

### KAGとは？

https://kddi-agile.com/

- もともと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のピーターさんのセッション！

![IMG_0044.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/42e45bc0-e586-7a4b-9050-593c5c1e45d6.jpeg)

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

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

- 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)

![IMG_0045.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/77c2e05b-de07-304e-0ad3-5800b360303e.jpeg)

### 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のカワジャさんのクロージングセッション！

![IMG_0046.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/2b2fcb89-cd20-21a8-2fd7-50c17fe499a1.jpeg)

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

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

### Momentoの紹介

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