Fastlyの基幹イベント「Yamagoya2024」導入事例セッションより

「ジャンプTOON」の裏側　単なるキャッシュにとどまらないCDN活用

ログはGCSとDatadogで2系統保存、構成管理はTerraformによるIaCで運用

　最後にモニタリングやデプロイなどの運用体制についても紹介された。

　モニタリングには、オブザーバビリティツールの「Datadog」を採用。複数のクラウドやサービスを横断的にモニタリングしたかったこと、社内での採用事例が多かったことからDatadogが選ばれた。インテグレーション管理でFastlyのキャッシヒット率などを収集して、Google Cloudのメトリクスと一緒にダッシュボード化しているという。

　また、Fastlyはさまざまな要因で503エラーを返すことがあるが、その要因ごとにログをグループ化することで、すぐに対応できる体制をとっている。

Datadogでモニタリング

　アクセスログに関しては、Google Cloud Storage（GCS）とDatadogの2か所に送信している。GCSにはすべてのログを送信して主にトラブルシューティングに、Datadogにはコストの観点から一定割合でログを送信しており、直近のエラーの確認や全体的な傾向分析に利用している。

アクセスログは長期保存用にGCS、直近のエラー確認用にDatadogに送信

　サービス環境に関しては、本番、ステージング、開発の3環境で構築。そして、Fastlyのサービスをそれぞれの環境および機能ごとに作成している。「設定ミスなどの影響を狭くするために、このような構成をとった」（長谷部氏）という。

　構成管理は、IaCツールである「Terraform」とその自動実行環境である「Atlantis」、コード管理には「GitHub」を利用している。Atlantisの機能で、プルリクエストはレビューを経ないと実行・マージできないように制限している。

　今後は、リリース時に見送った機能の実装を進めて行く予定だ。

　見送った機能のひとつが、APIサーバー「GraphQL」のキャッシュである。クエリの内容によっては一定時間キャッシュを返したいケースがあったが、クライアント側に意識させずにキャッシュすることが難しく、試行錯誤の末、実装を見送っていた。バックエンドのさらなる負荷軽減のために、何らかの方法で実現したいという。

　もうひとつ見送っていたのが、Fastlyのエッジコンピューティングサービスの利用だ。当初は、Next.jsにおける一部のミドルウェア処理をエッジにオフロードする予定だったが、予期しない動きがみられ、トラブルシューティングも不慣れであったため見送ったという。ユーザーのニーズをみながら、再チャレンジを検討しているそうだ。

　長谷部氏は、「現時点では、大きな問題も発生せずに安定して運用できている。今後も安全に運用できるよう、テストなども改善していきたい」と締めくくった。

■関連サイト

• ジャンプTOON
• Fastly