ServerlessDays Tokyo 2024
くりりん社内でのサーバーレスアプリケーション開発を、プラットフォームエンジニアリングを整備して迅速化・安定化させる取り組み
Main Track (Room A)
プラクティスをPlatform Engineering化
これまでは各チームが個々でアーキテクチャの選択を行っていたが、社内に既存であった知見が共有されないという問題が発生した。
アーキテクト専門のチームを設立することで、横串で横断したプラットフォーム構築をできるようにした。
フェーズ1
案件でうまくいった実績ベースでサンプルコードを作成
技術スタックの選定にはすでにいくつか存在していたスタックパターンから選定
→判断基準はドキュメント化
フェーズ2
アーキテクチャの運用
プロジェクト立ち上げ時などに使ってもらうことでサーバレス開発の迅速化・安定化
アーキテクチャ公開版↓
くりりんAWS Lambdaを支える技術
Main Track (Room A)
Lambdaの責任共有モデル（AWS側）
Security
LambdaはかつてT2 instancesを利用していた
ルーターで入ってきたリクエストを用意しているインスタンスに割り当てるという構成
Firecrackerを導入することで、インスタンス単位からmicroVM単位で稼働させられるようになった
Utilization
Lambda内のEC2インスタンスに均等に割り当てるとリソース効率が悪い
なるべく局所的に寄せて余った部分はオートスケールする分として持っておくほうがリソース効率が良い
局所的に寄せると急激なアクセスがくると対応しきれない
統計的な多重化を利用して相関関係のない多数を集める→機械学習を利用
Performance
Lambda側から見るInputはInputデータとコードzip
Container Imageを使うと最大10GB分のコードを使えるが、起動時に時間を要する（コールドスタート）
統計的に10GBのうち、4%程度のコードでコールドスタートに影響せず実行が可能である
Lambda内部にさまざまなキャッシュを用意しコールドスタートを緩和
チャンクの不要な重複を防ぐ
Availability
Shuffle Sharding
No Sharding
Poison Pill（不具合を起こすもの）が投入されると影響範囲は全てに及ぶ
Cell-based Sharding
Cell内に影響範囲が限られるが、同じCell内にいるアーキテクチャに影響が及ぶ
Shuffle Sharding
1つのクライアントに対して複数のShardをランダムに割り当てる
1つのShardで障害が起きても、他のShardに同じクライアントがあれば動作を担保できるため障害影響範囲が限りなく少なくなる
クライアントからリトライや迅速なフェイルオーバー
同じことが複数のワーカーで実現できる前提が必要
→リトライがあることで他のShardで実行が可能となる
まとめ
Lambdaとは
生産性向上を支援するために、 Serverless において大切にすること
くりりん実践！サーバーレス RAG 構築：Firestore ベクトル検索と VertexAI LLM 活用
Main Track (Room A)
RAGとは
大規模言語モデル（LLM）の出力の質を向上させるための技術
信頼できる専門性も理解した、最新かつ正確なデータを基に生成AIが回答を生成するためにRAGが必要
独自知識がない時の回答
- この店のメニューの前菜が見たい
- 「私はお店のメニューについて何も知りません。」とAIが回答してしまう
独自知識がある時の回答
- この店のメニューの前菜が見たい
- 「〇〇のメニューの前菜は以下の通りです」と回答ができる
Cloud Run
- コンテナをデプロイするだけで外部から到達可能なURLが発行
- トラフィックに応じて高速にスケーリング
- スケジュール、イベント駆動で処理を実行
- HTTP/2 WebSocket gRPCへ対応
- 高度なトラフィック管理が統合
- サービスメッシュのサポート（preview）
- トラフィック管理の強化
- 可観測性の向上
- 暗黙的なサービス感認証
- GPU対応（preview）
- 生成AIアプリにおけるLLMの稼働が可能
- 画像・音声認識などのオンライン実行
- プレビュー中は事前申請が必要
Vertex AI
- プロンプトにテキスト・画像・動画・音声・ドキュメントなどのデータだけでなく、複数のデータ（マルチモーダル）を含めることが可能
- テキストの多次元ベクトルデータを作成し、ベクトル検索を可能に
- モデルのチューニングも可能
- Model Garden
- Google製・サードパーティ製・オープンモデルなど、幅広いモデルの選択してAPIアクセス可能
- Agent Builder
- 開発者が自然言語またはコードを使用して、AIエージェントとアプリを構築できるローコードプラットフォーム
Firestore
- スケーラブルで麺点ナンス不要のサーバーレスドキュメントDB
- スキーマレスで柔軟なデータモデル
- 従量課金
- クライアントとリアルタイム同期可能
- Firebaseと統合
- 無料枠が存在
- ベクトル検索のサポート
- K最近傍（KNN）ベクトル検索が可能
- 開発の柔軟性とコスト効率を高めることが可能
- 複数のDB対応
- 1プロジェクト内でリージョン、また、Firestoreモードの種別を分けた複数データベースが作成可能
データ登録の例
- PDFがアップロードされる
- イベントをトリガーにPOSTリクエスト
- PDFデータを取得してchunk分割後、テキストエンべディングを作成
- ページ数の多いPDFだと検索の精度が悪くなるので、ページ単位や章単位でPDFを小分けにすると良い
- Fieldに対してベクトルインデックス作成
- chunk毎のベクトルデータや、メタデータ登録
データの検索
- クライアントからリクエスト
- プロンプトのテキストエンべディングを作成
- Firestoreでベクトル検索
- 取得したデータを背景に、LLMに生成リクエスト
- 期待する出力結果をレスポンスとして返す
- テキストだけではなくjson形式で返すことも調整次第で対応可能
- 入力・出力・関連情報をまとめてデータ保持
- プロンプトに対してどういった回答をしたのかを別で保存し、データ分析に活用する
- ML.GENERATE?TEXT関数を利用したクエリで要約評価
定期ジョブで分析を実行
- 保持データで完結可能な場合はBigQueryのジョブ機能で実行
- データやAPI連携、ロジックなどが必要な場合、Cloud Run jobsによる定期実行
評価用プロンプトを用意
- タスク
- 生成AIモデルに与えられたタスク（要約・質問応答など）を明確に記述
- 評価基準
- 出力結果の評価基準を具体的に定義（正確性・関連性・網羅製など）
- 期待される出力
- 理想的な出力例を提示することで、評価者が判断しやすくなる
- 評価方法
- 評価者がどのような観点で評価すべきかを指示（5段階評価・Yes/No評価など）
評価をデータやプロンプトに反映
分析結果を反映
- ドキュメント内容の改造や必要な情報の追加
- プロンプト構成・テンプレートの改善
- 正確性・網羅製をあげるための保持データ項目の追加
登壇資料
くりりんサーバーレスAPIのパフォーマンステストとアプリの未来
Main Track (Room A)
サーバーレスの課題
- コールドスタート
- リソース制限
- デバッグの課題
- 作業の重複
サーバーレスAPIの構築は実現可能か
- サーバーレスのオンデマンドスケーリングはAPIに最適
- きめ細かいスケーリング
- コスト削減
- より高速なイテレーション
サーバーレスAPI構築の課題
- 状態管理
- 複雑なアーキテクチャ
- ツールと関し
- レイテンシの増加とカスタマイズの制限
Postmanとは？
3,100万人以上のユーザーに使われているAPIコラボレーションプラットフォーム
PostmanはAPIを使う作業をより効率よく行うのに役立ちます
Postman APIパフォーマンステスト
実際のトラフィックをシミュレート
複数の並列ユーザーをシミュレートすることができる。
これにより、実際のシナリオでAPIのパフォーマンスを観察しながら、テストすることができる。
実行タイプ
- 固定
- ランプアップ
- スパイク
- ピーク
リクエスト応答時間をモニターする
レスポンス時間の平均を取得しておき、テストコードとして時間がかかりすぎていないかをテストすることが可能
なぜPostmanでパフォーマンステスト？
一度コレクションを作ってしまえば、色々な用途に使える
他のテスト同様にライフサイクルにおいてできるだけ早い段階から継続的に実施することが重要
パフォーマンステストとは？
一般的に、特定の作業負荷のもとで、システムが応答性と安定性の面でどのように動作するかを判断するために実施されるテスト
Postman Flowsとは？
API中心のアプリ（ワークフロー）を構築するためのビジュアルエディター
- 複数のAPIの連携・データの加工・出力結果の可視化など一連のアクションの自動化
- 既存のコレクションにあるAPIリクエスト設定や環境を活用可能
- フロー用のWebhookエンドポイントを公開して、外部からフローをトリガー可能
- 公開済みフローを自分のワークスペースにフォークやコピーして利用できる
AIアシスタント機能を使って自然言語でフローの構築アシストしてくれる
登壇資料
くりりんオンライン薬局のLLMマルチエージェントを支えるLLM Ops
Breakout Track (Room B)
サービス説明
- 相談が大量体験
- 医療アドバイザーに体調のことをいつでも気軽に相談できる
- パーソナライズ漢方薬
- 30種類以上の漢方薬からあなたに合ったものを月毎に提案
- 継続的なかかりつけ
今回の対象
薬剤師にチャットの返答をサジェストするためにLLMを活用
5〜6割、生成されたサジェストをそのまま返信できるレベルの精度まできている
返信率
LLMのサジェストをそのまま送ったほうが15%ほど返信率が高い
返信速度
LLMのサジェストをそのまま送った方が返信速度が早い
フローエンジニアリング
- ルールベースでLLM処理可能かを判定
- LLMで会話を分類しLLM処理可能かを判定
- LLMで次のフェーズに移るべきかどうかを判定
- LLMでメッセージを作成
- LLMで作成されたメッセージを評価し、一定の水準を下回ったら再生成して、クリアしたもののみをサジェストする
フェーズ
- 自動体質チェック
- 共感・深掘りフェーズ
- 薬提案前確認フェーズ
- 薬提案フェーズ
- 購入ボタンの送信フェーズ
フェーズ毎に会話のパターンや対応マニュアルが異なる
同様のエージェントでもプロンプトは異なる
フローエンジニアリングの設計
- 大きなタスク単位からプロンプトエンジニアリングを行い、精度が出ないと感じたら適切な単位に分割する
- プロンプトエンジニアリングは本番のデータをプロンプトに流し込んで実験を行う
- 精度向上はリリース後にも可能なので、この時点では精度向上に拘泥しすぎない
単一の巨大プロンプトの分割
1つのプロンプトで行おうとしている複数のタスクを分割することができるはず
フローエンジニアリングでは、タスクを分割しエージェントを組み合わせて最終的な目的を達成する
評価とは？
- AIの出力結果の良し悪しを定量的・定性的に判断すること
- 分類問題や回帰問題などであれば、単純に正答率や誤差を評価すればいい
評価方法
- オフライン評価
- オンライン評価
評価使用のパターン
- 期待するアウトプットと実際のアウトプットを比較してスコアリング
- LLMエージェントの出力の妥当性をLLMでスコアリングするLLM-as-a-Judgeも有効
LLM-as-a-Judgeの必要性
LLMの出力を人が評価するのは、工数。コスト・速度の観点から限界があるので、LLMにLLMの出力を評価させようというアイデア
LLM-as-a-Judgeの評価の妥当性は現時点だと人間が確認するのが吉
→LLM-as-a-Judgeの評価をLLM-as-a-Judgeでやるというような無限ループに陥りかねないため
LLMではなく機械学習などで評価することも可能ではある
リリース後のフローエンジニアリングのトレース
LangSmithによるトレーシング
LangGraphとLangSmithを活用することでフローエンジニアリングの処理の可視化と実験管理を実現
リリース後のオンライン評価
- LLMアプリケーションでは実施にどの程度ユーザーに役立ったのかやどの程度ビジネス上の数値を向上させたのかを評価すべき
- 一方で、KPIとなるビジネス指標への影響は様々な要因が混ざり合う上に、評価できるまでの時間軸も長くなるので、現実的にはその手前の評価軸でも評価する必要がある
データセットの運用と改善
データセットに対して新プロンプトやモデルで評価を実施して改善がみられたらリリースする
くりりんサーバーレスなユーザー認証認可の考慮事項と実践的プラクティス紹介
Breakout Track (Room B)
認証トークンをWeb Storageに入れてはいけないらしい？
Cookieに入れるほうが安全？
jsからアクセスできないようにする「HttpOnly」属性付きでないと、WebStorage利用とあまり変わらない（XSS対応策として有効ではない）
「Secure」属性付きの場合HTTPS通信時のみCookieを送信する属性（XSS対応策として有効ではない）
サーバーレスという特殊性と制約を考える
- 認可サーバーからもらったトークンを安全に保存する場所に悩まされる
- OIDC準拠、JWTなどモダンな認証認可の仕組みに依存しなければならない
- サーバーがないSPA構成ではクロスオリジンでHttpOnly属性付きのCookieを扱う手段がない
トークンライフサイクルの考え方
- どのようなユーザー経験を与えたいか
- セキュリティに関してどの水準までを考慮するかといった狙いを明確に定める
認証・認可トークンの種類
- アクセストークン
- リフレッシュトークン
- IDトークン
トークンの保存場所
- InMemoryStore
- アクセストークン
- WebStorage
- localStorage
- アクセストークン
- リフレッシュトークン
- sessionStorage
- アクセストークン
- localStorage
- Cookie
- Http Onlyなし
- アクセストークン
- リフレッシュトークン
- Http Onlyあり
- アクセストークン
- リフレッシュトークン
- Http Onlyなし
SPAでHttpOnly属性付きCookieを扱うために知っておくべきこと
- Cookieの仕様
- 厳格なCORSポリシー
Cookieについて知っておきたいこと
Cookie属性
- Expires
- Max-Age
- Domain
- Path
- Secure
- HttpOnly
- SameSite
CORSの基本を理解する
リクエストできて、レスポンスも正常に届いているはずなのに、なぜ中身が確認できない？
SPA + WebAPIではクロスオリジン構成が基本となる
HttpOnly属性のCookieをクロスオリジンで扱うには、厳格なCORSポリシーの対応が必要
発行済みトークンの無効化
- モダンアプリ開発で利用されるIDプロバイダーは、アクセストークンの無効化方法は提供されない
- リフレッシュトークンの無効化方法は提供される
- ステートレスなトークンの特性上、ブラックリスト方式が有効
登壇資料
くりりんサーバレス基盤で Gemini の性能を引きだすアーキテクトを構築した話 議事録生成から次の活用へ
Breakout Track (Room B)
issueの発見
- お客様との会議（会議内容を動画で保存）
- 議事録作成と整理
- エンジニア同行依頼
これを生成AIで改善する
アーキテクチャの解説
- CloudRun
- CloudStorage
- CloudLoad Balancing
- Identity-Aware Proxy
リクエスト上限の回避策
課題
容量が大きい動画をリクエストすることができない
解決1
署名付きURL
最初にStorageに動画を保存し、そのURLをGeminiに送って参照させる
課題2
HTTP/2通信
今後の活用
利用例1
利用者：動画編集をしている方
利用方法：等時間の動画からイベントのみ動画を切り取らせる
利用例2
利用者：ペットホテルの運営会社
利用方法：10分に1回オエッとの行動を観察しチャットにて報告
利用例3
利用者：動画からクリエイティブな記事や手順書を作成する方
利用方法：元となる動画から叩き台となる文書の作成
くりりんマルチクラウド環境におけるコスト最適化の実践
Breakout Track (Room B)
コスト最適化のために何をすべき？
誰がコストを見るべきか？
みんな忙しいということを必ず念頭に入れる
その瞬間だけ費用削減しても何の解決にもならない
→持続的コスト最適化サイクルの実践が重要
コスト分析専門チームの必要性
クラウドネイティブな最適化を推進していくために、ITと財務チームが一体となることが必要
ITと財務が一体となることによって、迅速なデプロイ・運用を行い最適化を実践
クラウド財務ガバナンスの一般的な課題
- 予算サイクル
- 固定予算で行こうと消費の動的な変化に対処するのは困難
- 費用に対する責任
- 使用量と費用超過の原因を可視化しづらい
- 支出管理
- OpEx（事業支出）中心の支出を効果的に制御が難しい
- 予測可能性
- 予測との差異が25%を超える
- リソース投資
- クラウドリソースに対して標準出来なデータセンターへの差異
FinOpsとは？
技術・財務・ビジネスを一体化する運用フレームワークであり、組織文化を変革するもの
過失を責めない文化を確立する
安心してリスクを取り、必要に応じて修正し、イノベーションを起こさせる学習と成長の文化を奨励することが肝要
費用超過や計算違いの原因を突き止める上で役立つナレッジの蓄積に集中し、過失を責めない文化を作る
過失を責めない文化≠説明責任の欠如
ナレッジの共有＝チームとしての心理的安全性
ビジネス価値を重視する
コスト最適化≠削減
ビジネスKPIによって費用価値は変動する
Google Cloud Best Practice
請求及びコスト管理ツールについて理解する
コストって誰でも見れていいものではない
どのプロジェクトのコストが最も高く、その理由は何かをあきらかに
必要なコンピューティングに対してのみ料金を支払う
コスト最適化手法はクイックウィン最適化
ABC（AWS Bikking Conductor）
- KPIを定義可能
- 請求グループ定義可能
- 組織階層のMargin設定可能
登壇資料
くりりんエンジニアじゃない人へのサーバーレスのすすめ
Breakout Track (Room B)
誰がやるのか（現場の人）
- 営業部
- 経営企画部
- 経理部
- 人事
- 総務
- 経営
全ての人々
不足しているならみんながやればいい
何をやるのか（サーバーレス）
- レポーティング
- データ連携
- イレギュラー
- 入力
- 出力
- 計算
全てに仕事に関係する行動
いつやるのか（いつでも）
- 昔からある安心のやり方
- 新たに発生
- できたらいいな
常に課題化
どこでやるのか（クラウド）
- AWS
- Microsoft
- SaaS
- API
自動化できる使い捨て環境
なぜすすめるのか（できる）
簡単に使える状況になってきているのを様々な人に知ってほしい
人の行動を変えるのは難しいが、その人に合わせて自分の行動を自動化する方が簡単
どうやってやるのか（NoCode）
生成AIでなんかやって → サーバーレスかつノーコードで
くりりん生成 AI による新しい UI/UX 〜 サーバーレスで実現する Generative UI の世界〜
Breakout Track (Room B)
Generative UI
生成AIがフロントエンドのUIを生成すること
Generative UIは何が嬉しいか
- チャットによるコード生成は開発者体験が悪い
- 目的に特化した生成AIの活用が可能に
- フィードバックループの速さ
Generative UIの応用ステップ
対話的なインターフェースでWebサイトを生成する
生成AIがHTMLのファイルを作り出し、ブラウザのifarmeに埋め込んで表示
Next.jsのStreaming HTMLをAWS Response Streamingで
ユーザー → Lambda → Amazon Bedrock
構造化されたテキストをUIに反映する
マークダウン形式のテキストを生成し、画面でレイアウトする
ユーザー → Lambda → Amazon Bedrock
→システムプロンプトが異なる
生成AIの結果をJSON形式にすることでUIに組み込みやすく工夫するJSON形式でパースできない場合、クライアントからリトライを行う
自律的なAIエージェントがUIを描画する
開発を自律的に行う生成AIを利用する
Claude 3 Tool Use
RAGの仕組みを応用したWebサイト生成
既存のソースやデザインシステムを参照して、デザインに一貫性のあるUIを生成する
登壇資料
くりりん静的サイトのCI/CDでも侮るなかれ！Docs as Codeに沿ったセキュアな開発プロセスの実践
Breakout Track (Room B)
Docs as Codeの基本概念・利用ツール
Docs as Codeとは？
コーディングと同様のツールでドキュメントを作成する手法
- マークダウンを性的なHTMLファイルに変換するためSSGが必要
ドキュメントの開発プロセス
- ローカル
- 中央リポジトリ
- CI/CDパイプライン
ローカル
まずはマークダウンでドキュメントを作成
図の描画ではDraw.ioとPlantUMLを利用
textlintでテキストファイルの文章構成
- textlintとは各種ルールに基づいて文章構成を行う性的解析ツール
- 認知不可を低減させるため、記載揺れ設定に独自ルールを追加
huskyによるGitコミット時の自動チェック
- huskyとはコミットなどのGitフックで任意コマンドを実行できるツール
- textlintとその他の静的解析を自動実行
中央リポジトリ
- GHASでシークレットスキャンとコードスキャンを有効か
- MkDocsカスタマイズ用のJavaScriptファイルもスキャンされるので安心
プルリクエスト作成時にGitHubActionsで自動テスト実行
リポジトリ全体を静的解析（ローカルは変更対象のみ静的解析）
プルリクエスト上でドキュメントのレビュー
レビューで承認されるまではマージ禁止
CI/CDパイプライン
CI/CDにCDK Pipelinesを活用
ビルドステージの流れ
- インストール
- 静的サイトファイル生成
- AWSリソース単体テスト
- AWS IaC Template生成
パイプライン自身の再構築（変更がある場合のみ）
アセットのアップロード
静的サイトのデプロイ
デプロイ後のIP制限テスト
くりりんいまあるチームにフィットさせる Serverless、そして Platform Engineeringへの挑戦
セッション参加していないので資料のみ添付
登壇資料
くりりんMomentoが考える開発者の未来
セッション参加していないので資料のみ添付
登壇資料
くりりんWebAssembly を使ったサーバレス開発の基礎と実践
セッション参加していないので資料のみ添付
登壇資料
くりりんCloud Run で作るサーバーレス アーキテクチャ 30 連発 - これのときはこう！
セッション参加していないので資料のみ添付
登壇資料