CloudNative Days Winter 2024

はじめに

ZIPAIRの技術チームとして、私たちは常に新しい技術やトレンドに触れる機会を大切にしています。その一環として、CloudNative Days Winter 2024に参加しました。本記事では、参加したセッションの内容をレポートとしてまとめています。

参加したセッション

転職したらゲーム基盤システムの移行が大変だった話 ~ 数百台のアプリケーションをGKE化、CloudSQL化させて苦労したこと勘所 ~

スクウェア・エニックスにおける、オンプレミス環境で安定稼働していたゲーム基盤を、GKE や CloudSQL を活用したクラウド環境へ移行するプロジェクトについて紹介されました。オンプレミス環境では、物理的な近接性によりネットワークが安定しており、ゲームのユーザー体験（UX）に影響しない高いパフォーマンスを維持できていました。しかし、クラウド移行では新たな課題が3点明らかになりました。

1点目に、オンプレミス環境では、プロセスは一度稼働すると安定して動き続けます。一方で、Kubernetesでは3ヶ月ごとの定期的なバージョンアップが求められるため、障害リスクが高い環境に適応する必要があります。
2点目に、オンプレミスでは物理的距離が近いため、通信遅延はほとんど発生しません。しかし、クラウド環境では2ms〜10msの遅延が起こりえます。リアルタイム性が求められるオンラインゲームでは、ユーザー体験に致命的な影響を及ぼすリスクがあります。
3点目に、オンプレミス環境ではMySQLを利用しており、障害が頻発していました。クラウド移行により、この問題を解決する必要がありましたが、新たなデータベース環境への移行には慎重な設計と計画が求められました。

1点目のプロセスの稼働特性について、Kubernetesにおいて、プロセスの終了時に未処理のリクエストが影響を及ぼさないよう、PreStopフックを長めに設定しました。また、タイムアウトの設定を最適化することで、プロセス停止時のリスクを軽減しました。
2点目のネットワーク遅延について、通信遅延を最小化するため、DNS解決を工夫しました。具体的には、単純なサフィックスではなくフルドメイン名での名前解決を採用しました。この手法により、DNSクエリの処理時間を削減し、遅延を抑えることができました。
3点目のDBのダウンタイムの問題について、MySQLからCloudSQLに移行することで、ダウンタイムを1秒未満に抑え、運用の信頼性を大幅に向上させました。CloudSQLは安定性が確実であったため、採用されましたが、一方でTiDBのような代替案の評価が十分に行えなかったことが、今後の課題として挙げられました。

成熟度別 Platform Engineering アーキテクチャ道場

本セッションでは、Platform Engineeringの導入と成熟化に向けたアプローチが紹介されました。Platform Engineeringとは、開発環境やインフラ環境を標準化し効率化する手法のことです。Platform Engineeringを成熟させるには、アプリケーション開発者とプラットフォームチームの責任分界点を明確にした上で、ステップバイステップで進めることが重要だと語られました。

成熟度モデルの4段階

Platform Engineeringの成熟度には4段階あり、開発に必要なライブラリのバージョン管理をどこまで行うかが一つの基準になります。
段階が進むほど、アプリケーション開発者の責任範囲が減り、プラットフォームチームの責任範囲が増えていきます。

1. 段階1: 開発者が自らバージョンアップを対応（完全手動）。
   • 初期段階では、各チームが独自に環境構築やバージョンアップを管理。開発者の手間を煩わせる。
2. 段階2: Helmなどのパッケージマネージャーを導入。
   • コマンド一つで更新可能になるため、生産性が向上。
3. 段階3: 実行環境をプラットフォームチームが管理。
   • 開発者はバージョンアップを意識せず開発に専念できる。
4. 段階4: 完全自動化されたPlatform。
   • 直接的な操作が不要となり、プラットフォームチームが全ての更新を管理。

まず、Platform Engineeringに取り掛かる段階1として、Project Templateの利用が挙げられていました。Project Templateとは、KubernetesマニフェストやDockerfileをGitリポジトリにホスティングする方法です。この手法により、開発環境におけるライブラリの依存関係を、少なくとも開始時点においては解決した状態で、開発をスタートできます。
ただし段階1では、Project Templateに沿って開発をスタートした後、各開発者がバージョン管理を各自で行う必要があります。この欠点を克服するため、段階2では、Gitリポジトリにパッケージマネージャーを導入します。パッケージマネージャーを利用することで、コマンド一つでバージョンを更新できるようになるため、開発者のバージョン管理の負担が軽減されます。さらに段階3に進めば、バージョン管理を含めたインフラの実行環境全体をプラットフォームチームが担うため、開発者は管理の煩雑さから解放され、開発に専念できる環境が整います。段階4では、段階3で広がったプラットフォームチームの責任範囲に対して、運用負荷を軽減するために作業を自動化します。例えば、Kubernetesクラスターのバージョンアップ作業などを自動化することで、手動作業を最小限に抑え、運用負荷が軽減されます。

EKSバージョンアップ工数削減大作戦~ Terraform化とE2Eテスト自動化でバージョンアップを効率化 ~

kubellでは、Amazon EKSを利用しており、クラウド環境の管理やバージョンアップに多大な工数がかかっていました。この状況により、SREチームへの依存が増大し、運用負荷が高まっていました。本セッションでは、これらの課題に対して、TerraformとAtlantisを用いて、どう解消したかが語られました。

これまでの運用には主に2つの課題がありました。
1点目に、リソースの管理をSREがローカルから実行する必要があり、SRE以外のメンバーは実行できない状況でした。
2点目に、SREが手動でバージョンアップを実施する必要があり、作業負担の集中や権限管理の煩雑さが問題視されていました。

これらの課題に対応するため、セッションでは、TerraformとAtlantisを用いた手法が紹介されました。Atlantisとは、Github上プルリクエストがマージされたタイミングで、Terraformのリソース変更を加えることができるツールです。したがって、TerraformとAtlantisを組み合わせて運用することで、プルリクエストベースでリソース管理する仕組みを構築できます。
この運用の変更により、1点目の課題に対しては、リソースの変更がUI上で完結し、SREだけでなくアプリケーション開発者でも変更作業を実施できるようになりました。
次に2点目の課題に対しては、本番稼働前のE2EテストをKubernetesのE2Eテストツールkibertasが紹介されました。kibertasを使って自動化することで、EKSのバージョンアップ作業の工数削減を実現したことが強調されていました。
本セッションでは、これらの解決策によってTerraformを活用した効率的な運用が可能になり、全体の作業負荷が軽減に加えてバージョンアップ作業の安全性も向上したという具体的な成果が語られました。

クラウドコストと使用量を最適化し、ビジネス価値の最大化へと導く「FinOps」の実践アプローチ

クラウド利用の普及に伴い、コスト管理の重要性が一層高まっています。一方で、適切なコスト管理ができずに無駄な出費が増えるという課題が浮き彫りになっています。

適切なコスト管理が進まない要因として、主に2点挙げられます。1点目は、クラウドコストの透明性が低いため、どのプロジェクトやチームがどの程度リソースを消費しているのかが明確でないことが挙げられます。2点目は、クラウドコスト削減の取り組みが一部の担当者に依存し、各部署と連携が取れないことです。そのような状況では、コスト管理を含めた全社的な最適化が進みづらくなってしまいます。

これらの課題に対し、本セッションではFinOpsというクラウドの支出を最適化し、クラウドリソースの効率と価値を最大化することを目指す手法が提案されました。
1点目の課題に対して、FOCUS（FinOps Open Cost and Usage Specification）というクラウドの費用や使用量・課金データの標準仕様が、鍵となります。FOCUSを利用することで、課金データを標準化し、コストの可視化を支援します。
また、2点目の課題に対しては、FinOpsには以下の6つの原則が参考になります。

1. 組織内の各部門チームは協力する必要がある
2. 意思決定はクラウドのビジネス価値に基づいて行うこと
3. 全ての人が自分のクラウド利用量に当事者意識を持つこと
4. FinOpsデータはアクセスしやすくタイムリーであるべき
5. 組織横断の専門チーム中心でFinOpsを推進すること
6. クラウドの変動費モデルを最大限に利用すること

上記のなかでも、特に「組織横断の専門チームを中心に運用を進めること」が重要とされました。専門チームが主導することで、1つ目の原則についても、各部門が協力しやすい体制を築けるからです。
本セッションでは、これらの取り組みを通じてコスト管理を進めやすくなるだけでなく、チーム間の協力体制が強化されることで、ビジネス価値を最大化する実践方法が紹介されました。

Woven by ToyotaのFinOpsの取り組み

Woven by Toyotaでは、クラウドリソースの利用が拡大する中で、コスト管理の重要性が増加しています。特にクラウドの運用に伴う費用が増加したことで、企業全体の課題として浮き彫りになりました。

課題の1点目として、データ転送コストが急増し、k8sクラスター内でのデータコピーに無駄が生じている点が挙げられました。
次に2点目の課題として、急激なコスト増加を抑止する仕組みが不十分で、アラート機能が限定的であるため、問題の早期発見が困難でした。
さらに3点目の課題として、保存データが増え続けることでストレージ費用も高騰していました。

これらの課題に対し、Woven by Toyotaでは、独立したFinOpsチームを結成し、効率的なコスト管理に取り組みました。
まず1点目の課題に対して、ダッシュボードを活用してデータ転送状況を可視化し、k8s内でのデータコピー問題を特定・修正しました。
次に2点目の課題に対して、アラート機能を強化し、異常なコスト増加に迅速に対応できる仕組みを導入しました。
さらに3点目の課題に対して、保存データに関しては、Amazon S3 Intelligent Tieringを活用し、頻度に応じたストレージ利用を実現しました。
これらの取り組みにより、クラウドコストの削減と運用効率の向上を両立させるための実践的な方法が示され、今後の参考となる内容でした。

障害特定が超爆速に！Observabilityで問題解決力アップ ~ セブン&アイ・ネットメディアにおけるInstanaの活用事例 ~

セブン&アイ・ネットメディアでは、マイクロサービスアーキテクチャを採用するシステムで、複雑な依存関係の中で障害発生時の原因特定が重要な課題となっていました。障害対応を迅速化することは、ユーザー体験の向上とビジネス継続性の観点から必要不可欠です。

しかし、従来の監視ツールでは、アラートが頻発するのにもかかわらず、問題の根本原因を特定するまでに数時間を要するケースが多発していました。複雑な依存関係を持つマイクロサービス環境では、どの部分で障害が発生しているのかを突き止めるのが非常に難しく、迅速な解決が求められていました。

この課題を解決するために、Instanaというオブザーバビリティツールが導入されました。このツールにより、複数サービス間の依存関係やエラー箇所をタイムライン形式で可視化し、障害特定を数分で行うことが可能となりました。また、Instanaは障害対応だけでなく、性能試験にも活用され、データベースのボトルネックなどの課題を迅速に特定し解決する支援しています。
これらの取り組みの結果、障害対応や性能試験の効率が大幅に向上し、チーム全体の運用負荷軽減につながったと報告されていました。

そのCIは本当に役に立っていますか？ ~ 高品質なCIプロセスを実現する設計術 ~

CI/CDパイプラインの普及に伴い、開発の効率化が進む一方で、新たな課題も生じています。特に、CIプロセスが長時間かかる場合や、重要なエラーが見逃される場合、開発のスピードや品質に影響を及ぼします。

具体的な課題としては、2点挙げられます。1点目は、解析範囲が広すぎることで不要なファイルまで検査対象となり、時間がかかってしまう点です。その際に過去のコミット分までCIが実行されることでリソースが無駄に消費される問題も指摘されていました。
また2点目に、特定のCIに対して見て見ぬふりを続けた結果、致命的な解析エラーがリリース直前に発覚するケースが挙げられました。

このような状況を改善するために、本セッションでは、CIの多岐にわたる設計手法が紹介されました。
1点目の課題に対しては、差分解析と並列実行という手法が挙げられました。
差分解析とは、最新のコミット以外のプロセスをキャンセルする仕組みです。例えば、GitHub Actionsの「cancel progress」機能を活用すれば、無駄なリソース消費を抑制できます。それにより、CIを効率的に実行でき、成功や失敗にいちはやく気づくことができます。また並列実行とは、依存関係のないコードはできるだけ並列に実行して、キャンセルするという手法です。それにより、CIを短時間で実行できます。
次に2点目の課題に対しては、検知結果を適切に抑制することが挙げられました。具体的には2つあり、1つめにプロジェクト上仕方のないエラーが出る場合は、あらかじめ抑制するように設定しておきます。また、2つめにテストのカバレッジ率に対して、しきい値を設定しておきます。プロジェクトによっては、分岐を全て網羅することが、現実的でない場合もあります。その際は、例えばテストのカバレッジ率が95%を下回った場合にFailとみなし、確実に通知される仕組みを整えることで、リリース前の問題を未然に防ぐことができます。
本セッションでは、開発者にとって使いやすいCI環境を構築する具体的なノウハウが共有されました。

まとめ

本記事では、CloudNative Days Winter 2024の各セッションの概要についてお伝えしました。

これらのセッションは、モダンなインフラやプラットフォーム運用の現場課題と解決策を具体的に学べるものでした。それぞれのセッション内容を深掘りすることで、今後の運用や改善に活かせる知見が得られたと感じます。

各セッションのアーカイブ動画はすでに公開されているので、本記事を読んでご興味を持たれた方は、そちらも併せてご確認ください。

CloudNative Days Winter 2024 タイムテーブルはこちら