Strapチームで主にバックエンドを担当していますやっはーです！！
この記事は Goodpatch Advent Calendar 2023 の 22日目の記事になります。
Strapのセキュリティホワイトペーパー でも記載しているように、StrapはGoogle Cloud Platform(GCP)上のFirebaseを中心としたマネージドサービスのみで稼働しており、完全にサーバーレスなアーキテクチャで運用しています。
GCP/Firebaseの選定理由は「 B2B SaaS バックエンドにFirebaseを選定した理由」として以前も書きましたが、要約すると以下の通りです。
- リアルタイム同期のサポート： ユーザー間のリアルタイムコラボレーションを実現
- 認可・バリデーション機能： データの安全性を確保
- コスト削減： 人的コストと金銭的コストの低減
- セキュリティ要件の満足： B2B SaaSのセキュリティ基準への適合
- 開発効率の向上： 効率的な機能開発 （GPT-4にまとめてもらいました。）
今回はその後Strapの運用を続けてきて、改めて感じているGCP/Firebaseのメリットと今後の課題などについてご紹介できればと思います。
プロダクトにとって良かったこと
とにかくサービスが安定していて、速い
バックエンドとしては本当に申し分なく、速くて安定しています。
メインのデータベースであるCloud Firestoreは、過去２年において、特に日本時間の日中でサービスに影響を与える障害はほぼ皆無でした。
CDNとしても稼働するFirebase Hostingや、他の周辺サービスでは少しエラーを検知することはありましたが、毎月行っている振り返り会でも大きな問題になるようなことはありません。
サービスの規模に合わせて成長していける
Cloud Firestoreについてはうまくデータ設計時点で分散することができていれば、特に調整すら行う必要なく、アクセスが増えた現在でも全く問題はありません。
スキーマレスである点でも、差分をフロントエンドのアプケーションで吸収できるので、機能拡張していく上では非常に助かります。
WebAPI的に利用しているFaaSのCloud Functionsについては、当初は性能を強化しても限界が見えていましたが、新アーキテクチャのV2になってからは、同時実行数の調整が可能になったことなどで、よりスケーラブルになり、大量の処理も捌けるようになりました。
また、認証処理を事前にしてくれるCallable関数があるので、バックエンドの開発が苦手なメンバーが入っても安全にCloud Functionsで開発を進められます。
ほとんどのケースで安い
Cloud Firestore も Cloud Functionsもそのサービスの利用自体はコストが本当に安いです！
Strapでは１名の開発者に１つ以上、20個近くの環境を稼働させていますが、Cloud Functionsの稼働を常時稼働していないコールドスタンバイの状態に調整できるので、従量課金であるFirebaseでは、トラフィックの少ない開発環境においては全部まとめても、月に数千円で済んでいます。
本番環境でもFirebaseのアプリケーション群自体はそこまでかかっておらず、一番コストが高いのは、実はGCPのサポート費用と監査ログの費用です。
（ここはコストを払ってでも守りたい部分ですよね。）
開発者にとって良かったこと
本番と同じ環境が容易に構築できる
先にあげたコストのメリットもあるため、複数の環境を立ち上げるのが躊躇せずにできます。
本番環境とほぼ同じ（Cloud Functionsは性能を少し落としているが）で稼働できるので、環境による挙動の違いなどはなく、エラー発生時の再現も比較的簡単です。
ちょうど良い速さで進化してくれる
著名なフレームワークやOSなどは、時に速いペースで進化していくことがあります。
私も過去に、Breaking Changeや速すぎる進化に追いつくのに苦労して、本質的な改善ができないことがありました。
しかしながら、Firebaseは後方互換性を大切にしつつ、ちょうど良いペースで少しずつ進化してくれているように感じます。
アップデートも取り入れやすく、Breaking Changeもほとんど感じません。
（これは、私個人の印象かもしれませんが・・・)
拡張できる選択肢が多い
認証やFaaS、ロギング、検索などにおいても、Identity PlatformやCloud Runへの拡張をはじめ、BigQueryはもちろん、Algolia, Elasticsearchとの連携など他サービスを用いて拡張できる選択肢は多いです。
GCPの機能としても他にも様々なサービスとも連携できますし、Firebaseでの外部サービスとの連携についても、Firebase Extentionsなどでも積極的に紹介されています。
運用面で良かったこと
Googleとの役割がはっきりしている
「Google Cloud のセキュリティ プロダクトとサービス」に記載のあるようにGoogleとの役割ははっきりしており、PaaSだけなら管理する部分は Content, AccessPolicy, Usage, Deployment, Web application security だけなので、よりアプリケーション自体の実装に集中できます。
基盤部分のセキュリティが最強
先ほどもあげたこの「Google セキュリティの概要」のページは熟読すると本当に勉強になります。
Googleがいかにセキュリティを重要視し、組織として立ち向かっているかがよくわかります。
Strapはセキュリティチェックシートの記載依頼も多いですが、このインフラなら自信を持ってOKと回答できます。
権限のわかりやすさ
GCPは他の主要クラウドと違って、「プロジェクト」という概念で区分けされます。
この単位でIAMや課金も管理できるので、リソースの整理がしやすいです。
また、Google Groupでも権限追加できるので、Groupの管理がそのままIAMの管理にも適用できます。
上記のように多くのメリットを享受しながらGCPのマネージドサービスで運用しており、StrapはISO27017（クラウドセキュリティ）認証も取得することができました。
ただ、もちろん課題として見えてきたこともあるので、少しだけ触れておきます。
今後の課題
本当にFirebaseから離れられなくなってきた
当初はある程度サービスが進行していけば、他のクラウドやサービスにも乗り換えられるタイミングが見えてくるかなと思っていました。
しかしながら、ここまで充実しているクラウドはまだ他になく、特にCloud Firestoreは現時点では唯一無二のサービスだと感じているので、まだまだ移行が難しい状態です。
そのため、改善したくてもFirestoreの制約できないというケースも出てきました。
もちろんSurrealDBなど代替になりうるものは引き続き探していきますが、今は制約を工夫しながら乗り越えて、アプリケーション自体の成長と改善に注力していきたいので、ちょうど良いのかもしれません。
こんなに楽して良いのかしら。。。
私は他のサービスでもインフラ周りを少し見ていますが、比較すると運用が楽すぎます。
ミドルウェアや言語の脆弱性についても、ほとんどの対応はIaaSの領域のことが多く、Firebaseを中心としたこのアーキテクチャの場合、緊急で対応したようなケースは現時点ではありません。
もちろん、それらの情報は追いながらサービスへの影響は引き続きチェックして、アンテナは貼り続けていきたいと思います。
まとめ
改めて整理してみると、GCP/Firebaseで開発してきて良かったなと思うことが多いですね！
サーバーレスなアーキテクチャとマネージドサービスによる運用は一度経験したらもう離れられないかも。。。
とにかくアプリケーションのメインロジックに注力できる点で、やっぱり最高だなと思っています。
また、これらの運用の知見なども溜まってきてはいるので、チームで相談に乗れることもあるかもしれません。
もしくは一緒に開発・運用する仲間も募集しているので、カジュアル面談もぜひお気軽に🤗
