myTOKYOGASフロントエンドのインフラ構築をふりかえる🌱
こんにちは！東京ガスCX推進部デジタルマーケティンググループでエンジニアリングチームリード兼SREをしております、杉山です。
及川の投稿にもありましたとおり、このたび弊社会員サイトmyTOKYOGASがリプレイスされました！🎉 私たち内製開発チームはフロントエンドをフルリプレイスし、その中でも私はインフラ部分を一手に引き受けて構築しましたので、その振り返りをしたいと思います。
及川の記事、私の前回記事について、よろしければ以下もご覧ください。
インフラ構成概要
弊社はAzure をメインのクラウドとして活用していること、またスケジュールの都合もあり、今回はAzure + Terraform を利用しての構築となりました。前職AWSの私がAzure でゼロイチから構築するのも不思議な感覚でしたが、今回はキャッチアップしてがんばりました💪 主に以下のサービスを利用して構築しています。
Azure App Service : BFF コンテナイメージのデプロイ用
Azure Static Web Apps : Next.js SSG コンテンツのホスティング用
Azure Application Gateway + WAF
Azure Database for PostgreSQL Flexible Server (version14)
Azure Cache for Redis
Azure CosmosDB for MongoDB
Azure Blob Storage : 静的コンテンツ配信用
Azure Container Registry
Azure Monitor + EventHub + Azure Functions : Datadog 連携用
Event Grid + Azure Functions : コンテンツ格納処理用
AzureAD B2C : 内部機能実現のため利用 (ユーザー用IdP ではありません)
BFF はWeb 用とモバイル用に分かれており、Next.js も含めたコンテナオーケストレーションの採用も考えたのですが、この規模でKubernetes を採用しても運用負荷のコストに見合わないこと、マネージドサービスのAzure Container Apps はVNet 統合した際のサブネットのCIDR 制約が厳しいことから、App Service を選択することとなりました。AWS でいうECS のようなサービスがあったら良かったのですが、ここは私のAzure 知識が足りなかったかもしれません。
他にも、CDN は Akamai を利用しています。ただ、ここはサービスプロバイダーが異なることや、所管部署が異なることもあり、若干の運用負荷を感じています。 (もちろんAkamai自体は素晴らしいサービスですよね) サービス同士がネイティブに統合されていたほうが楽だったかな、と。
少し脱線して、これは個人の考えですが、せっかくなら運用負荷とチャレンジのバランスを見つつ、Cloudflare を使っていきたいなあ、と思っていたりします。最近、Cloudflare のサービスラインナップが素晴らしくて魅力的だなあ、と。もちろんmyTOKYOGAS というサービスを安定してお客さまにお届けすることが最優先事項ですが、エンジニアとしては新しい領域へチャレンジする気持ちは忘れたくないですよね・・・！
監視・運用について
監視にはDatadog と PagerDuty を利用しており、Slack とのIntegration も活用しながら運用を行っています。フロントエンドの担当領域はBFFも含みますので、ダッシュボードでのリソース状況確認や、NestJS が出力するログの確認、ログをフックしてDatadog Monitor で通知する… といった運用はもちろん、RUMも活用して、お客さま体験の向上に努めています。
また、本番環境のデータにアクセスするため、コピー・アンド・ペーストを禁止したAzure Virtual Desktop を利用したり、開発用のMacBook にゼロトラストの世界観を目指した製品導入を行ったり、よりセキュアで開発者体験の優れた環境を実現しようともしています。Developers たちがストレスを感じることなく、日々のOps をこなしていくために、開発者体験は非常に重要であると考えています。ですので、コーポレートエンジニアリングと言われるこの領域については、今後も力を入れていきたい所存です。
大変だったことなど
すべてゼロベースでの構築となったため、大変なことは多かったですが、これまでAWS を利用してばかりでしたので、Azure 独自の考え方を理解すること、サービス仕様を深く知らない状態でTerraform のコードに落としていくことは特に大変でした。一方、Terraform のコードにすることでサービスの理解が深まるという点は、狙い通りだったかなと思います (個人の負荷を除けば、ですが苦笑) マルチクラウド運用をされている方々を改めてリスペクトする次第です。
ビルディングブロックとして、このサービスとこのサービスを組み合わせて〜というふうに考えていくAWS とは異なり、Azure のサービスは一つのサービスに多くの機能があり、それぞれの必要性を精査することにも時間が掛かりました。検索しても公式のページが全てを占めることも多く・・・ドキュメント全部読む→わからない→また読む、の繰り返しだった気がします。特にApplication Gateway と App Service は出来ることが多くて難しかったです・・・その中でも、サポートの方には助けていただいてばかりで、改めて感謝申し上げたい所存です。
また、Azure Functions に関しては、AWS Lambda と同じノリで行くと大変な目に遭うなあ、と感じました。最初は「App Service じゃないのに、App Service Plan があるの…？」「インスタンスを意識する？冗長化をユーザーで行うの？」といった部分が、サーバーレスとは？といった感じで中々に難しかったです。
そんな中、これは便利かも？と感じたのは Static Web Apps でしょうか。
Next.js で SSG した静的コンテンツをホスティングするにあたって、GitHub Actions でビルドからホスティングまで一気通貫で実施できて、非常に便利でした。AWS だと、ECS やEKS で配信したい場合、Node のベースイメージからビルドした静的ファイルを、Nginx などのイメージにホスティングする形になりますかね・・・？もしくはシンプルにS3 を利用する形でしょうか。このあたりをマネージドに実施してくれるので、個人的には非常にありがたかったです。ただ、ビルドなどを工夫されたい方には不都合がありそうでしょうか(これはどんなマネージドサービスにも言えますけども
今後に向けて
まずは日々の運用をしっかりと行い、お客さまにご迷惑をおかけしないよう努めることが最優先事項です。リプレイスして日も浅いので、レスポンスタイムやエラーレートがどのように変動しているか、データを集めて Developers たちと会話しながら、日々の改善活動に取り組んでいます。24/7で提供しているサービスになりますので、運用をアウトソーシングすることなく、Developers たちも日々のオンコールに参加していますし、その中で得たナレッジを貯めることで、Ops の中から次の改善につなげていくサイクルが出来てきていると感じています。
また、ビジネス部門の方々もこれらの情報にアクセスできるよう、Datadog でダッシュボードを用意しており、メール配信などでのアクセス影響など、意思決定のために進んで情報を集めてくれています。
内製開発で得られた成果は多くありますが、ロール問わず、メンバーそれぞれが越境したオーナーシップをもって動けるようなチームになったということが、何よりの成果なのではないか、と個人的に思っています。
今後 SRE としては、信頼性の高いシステムを目指し、SLO や SLI の設計などにもチャレンジしていきたいと考えている次第です。
そして気が早いですが、私の方はAmazon EKS を利用した次なるプラットフォームを構築しております。今後、内製開発の領域を拡げていくことをチームとしても期待されており、その中には肥大化したサービスたちのマイクロサービス化も含まれています。この期待に応えるために、チームも私もどんどん進化していきたいと考えています💪
このチャレンジに共感いただける方がいらっしゃいましたら、ぜひ以下のWantedly もご覧ください。チームとプロダクトを成長させていきたい、そんな熱い想いを持った方と、お話できたら幸いです！
それでは、最後までお読みいただき、ありがとうございました！また次回の投稿でお会いしましょう👋