LaravelとBrefによるチームファーストのサーバーレスエンジニアリング

録画

https://www.youtube.com/watch?v=41JNqwdVmfk

プラットフォームエンジニアリングのアプローチによるサーバーレス開発

• CNCFの定義：サーバーを管理することなくアプリケーションを構築・実行すること。
• 利点：
• [ 1 ] 運用上のオーバーヘッドを削減できる。
• [ 2 ] コストを削減できる。
• [ 3 ] 開発を迅速に進められる。
• [ 4 ] サーバーのプロビジョニングが不要になる。

導入の目標とルール

• [ 1 ] 目標：
• 顧客が抱える現実の問題を解決する。
• [ 2 ] ルール：
• 実質的な価値を生み出す。
• PHPチームの働き方に適合させる。
• 一人だけでなく、チーム全体が保守できるようにする。

ケーススタディと得られた教訓

• [ 1 ] パートナーデータ用のシンプルなAPI：
• Amazon API GatewayとAWS Lambdaを使用し、データをAmazon S3へ保存した。
• トラフィックが200倍に増えてもパフォーマンス上の問題はなく、その点では成功した。
• 隠れた問題：保守できるのが一人だけだった。
• 教訓：問題は言語（Python）ではなく、チーム文化との不一致と不慣れなツールにあった。
• [ 2 ] 機械学習向けサーバーレスプラットフォーム：
• コストを削減でき、データサイエンティストからも好評だった。
• 問題：一般の開発チームは利用できなかった。
• 教訓：専門家だけでなく、主要な開発者層のためのソリューションが必要だった。
• [ 3 ] AWS Amplify：
• AWS Amplifyを使った実験の詳細は途中で途切れているが、より広いチームに適した持続可能なサーバーレスソリューションを探す、もう一つの試みだったと考えられる。

主なポイント

• [ 1 ] 共同オーナーシップ：
• 真の成功には、共同オーナーシップとチーム文化への敬意が必要である。
• [ 2 ] チームへの適合：
• ソリューションはチームの働き方に合い、チーム全体で保守できなければならない。

まとめ

• サーバーレスを効果的に導入するには、チーム文化を理解して尊重し、保守性を確保し、すべてのステークホルダーに実質的な価値を生み出す必要がある。

新しいプロトタイプで直面した課題

• [ 1 ] 当初の反応：
• サーバーレスを使用した新しいプロトタイプは、使い慣れたツールによって培われたラボチームの「体に染み付いた感覚」から外れていたため、抵抗を受けた。
• [ 2 ] 得られた教訓：
• 大きな変更を導入する前に、使い慣れたツールへの信頼と安心感を得ることが重要である。

チーム間で異なった経験

• [ 1 ] Rubyチーム：
• サーバーレスの導入に成功した。
• [ 2 ] PHPチーム：
• 認知負荷が高く、導入に苦戦した。
• [ 3 ] 気づき：
• 成否の違いは、認知負荷とツールへの習熟度に起因していた。

プラットフォームエンジニアリングへ移行する新戦略

• チーム全体がサーバーレスを利用・保守できるよう、プラットフォームエンジニアリングへ移行する。

目標の再評価

• 以前の目標：サーバーレスプロジェクトを単にリリースすること。
• 新しい目標：チーム全体が運用できるサーバーレスプロジェクトをリリースすること。
• 成功指標：関数の数ではなく、チームの自信。

PHPチームでサーバーレスを機能させる

• 使い慣れたツールの必要性：
• PHP開発者には、安心して使えるツールが必要だった。
• カスタムランタイム：
• 2018年という早い時期から、Lambda上でPHP用カスタムランタイムを使い始めた。

ソリューション：LaravelとBref

• [ 1 ] Laravel：
• 開発者はすでにLaravelを信頼し、使い慣れていた。
• [ 2 ] Bref：
• Lambda上でPHPを実行する際の複雑さをBrefが処理した。
• [ 3 ] 組み合わせたソリューション：
• 既存のワークロードを維持しながら検証を行い、サーバーレスの利点を得られるようになった。

最初の本番アプリケーション

• [ 1 ] アプリケーション：
• 大容量CSVファイルの処理。
• [ 2 ] 技術スタック：
• Amazon S3 Selectを使用してLambda内でデータを絞り込み、予測可能なパフォーマンスを確保した。
• [ 3 ] 結果：
• 高速な処理を実現し、サーバー管理も不要になった。

チームへの導入と成功

• [ 1 ] 若手開発者：
• ドキュメントに従うだけで、サーバーレスアプリケーションを開発・デプロイできた。
• [ 2 ] 役割の変化：
• 発表者の役割は、ボトルネックからコーチへと変わった。
• [ 3 ] 再現性：
• このアプローチは再現可能になり、一人の専門家に依存しなくなった。

まとめ

• サーバーレスの導入を成功させるには、チームの力学を理解し、使い慣れたツールを活用し、チーム全体が自信を持ってサーバーレスアプリケーションを運用できる環境を育てる必要があった。

サーバーレスで生じた新たな課題

• サーバーレス固有の問題：
• コールドスタート、タイムアウト、メモリ制限。
• Laravelアプリケーション全体を一つのLambdaで実行する「Lambda Lift」では、パッケージサイズの増大や権限の複雑化といった課題が生じた。

実践的な解決策

• [ 1 ] 緩和策：
• Lambda Layersと、機密性の高い関数用に分離したIAMロールを使用した。
• タイマー処理にはプロビジョンドコンカレンシーを採用し、コールドスタートの管理にはイベント駆動型のアプローチを取り入れた。
• [ 2 ] 妥当性の確認：
• 評価の高いエンジニアとの議論や検証により、Lambda上でモノリスを実行することの実用性が確認された。

得られた教訓

• [ 1 ] マイクロサービス対モノリス：
• 完璧なマイクロサービスアーキテクチャが常に必要とは限らない。
• 各チームにとってLambda Liftは、共同オーナーシップと機能の迅速なリリースを可能にする実用的な選択肢だった。
• [ 2 ] チームの自信：
• 特定のアーキテクチャよりも重要である。

ソリューションの展開

• 再利用可能なテンプレートと標準コマンド：
• 新しいチームがゼロから始めずに済むよう、再利用可能なテンプレートと標準コマンドを作成した。
• プラットフォームチームのサポート負荷を軽減した。

プラットフォームエンジニアリング

• [ 1 ] 定義：
• 開発チームの認知負荷を下げ、機能をより迅速にリリースできるようにする共有サービスを構築すること。
• [ 2 ] 指針：
• プラットフォームに関するCNCFホワイトペーパーなど、業界のベストプラクティスに従った。
• [ 3 ] Team Topologiesモデル：
• プラットフォームチームが一般的な問題に対する標準ソリューションを提供して認知負荷を軽減し、将来のチームが機能開発に集中できるようにすることを目標とした。

プラットフォームの設計

• [ 1 ] 既存チームへの適合：
• 既存のチーム構成と文化に合うようプラットフォームを設計した。
• [ 2 ] 認知負荷の軽減：
• 不安を生むような複雑なサーバーレスアーキテクチャを避けた。
• ロードバランサーを使用し、適切なコンピューティング先へトラフィックをルーティングした（例：PHPチームが使い慣れたLambda）。
• [ 3 ] データベースの選択：
• 開発者が使い慣れたSQLコマンドを最小限の変更で利用できるよう、MySQL互換サービスのTiDBを選択した。

ローカル開発体験

• ツール：
• DockerとLocalStackを使用し、開発者が同じPHPコマンドを使ってノートPC上でアプリケーション全体を実行できるようにした。
• 導入時の障壁が大幅に下がった。

変革による成果

• [ 1 ] 役割の変化：
• 発表者の役割は、ボトルネックから支援者へと変わった。
• [ 2 ] 成功の拡大：
• このパターンを複数のチームへ展開した。
• 新しいチームをサーバーレスプロジェクトへ参加させるまでの時間が大幅に短縮された。

まとめ

• 認知負荷の軽減、使い慣れたツールの活用、再利用可能なテンプレートと標準ソリューションの提供に重点を置くことで、プラットフォームエンジニアリングのアプローチは、チームがサーバーレス技術を導入・展開する力を変革した。

プラットフォームの主な特徴

• [ 1 ] セルフサービスシステム
• コマンドと自動化されたCI/CDパイプライン。
• サポートチケットを不要にし、開発者が自分の作業に集中できるようにする。
• [ 2 ] ガードレール
• 構造化ログやアラート機能付きのSentryなどのツール。
• 問題の解決方法を示すガイダンスとLambda関数が含まれる。

プラットフォームの進化

• 初期段階：緊密な協力。
• 現在の段階：プラットフォームをセルフサービス製品として提供する「X as a Service」モデルへ移行中。
• 目標：セルフサービスを文化の自然な一部にする。

継続中の取り組み

• プロセスへの統合：
• スプリント計画、コードレビュー、振り返りにサーバーレスのパターンを組み込む。
• チーム全体がシステムを安心して扱えるようにする。

3段階のロードマップ

• [ 1 ] 適応：
• テンプレートとコーチングから始める。
• [ 2 ] 標準化：
• 標準になるまでテストとデプロイを自動化する。
• [ 3 ] 拡大：
• パターンをより多くの製品へ展開し、改善を続ける。
• [ 4 ] 成果：
• このシンプルなサイクルにより、チームの生産性が高まり、将来への準備が整う。