Flywheel の事業を加速させた Google Cloud のマネージド サービス
Google Cloud Japan Team
※この投稿は米国時間 2021 年 1 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: マネージド WordPress ホスティングを専門に扱う WP Engine の子会社 Flywheel は、35,000 以上の代理店やクリエイティブなブランドのサイトを運用するためのプラットフォームとして、堅牢なインフラストラクチャを必要としていました。Flywheel は Google Kubernetes Engine に移行することで、必要としていた信頼性の獲得とリソースの活用を実現しました。さらに、アプリケーションを Google Cloud のマネージド サービス上で運用できる多層のクラウドネイティブ アプリケーションとして再設計し、新たなレベルでの業務の効率化と費用の管理を達成しました。その方法の詳細をお読みください。
Flywheel は広告代理店に対する効果的なウェブサイト ソリューションの提供を専門としており、WordPress の CMS 向けにカスタム構成かつ最適化されたプラットフォームを構築しています。専用リソースの提供、堅牢なワークフロー ツール、WordPress のエキスパートの配備、さらにサイトのスピードを重視することで、優れたサイト パフォーマンスとユーザー エクスペリエンスを提供しています。
優れたサイト パフォーマンスとユーザー エクスペリエンスを成し遂げるには、ユーザーの期待に応えて進化する WordPress に合わせて刷新していく必要があります。デジタルが新たな標準となり、ますます競争が激化する状況の中で、Flywheel のプラットフォームに対するユーザーの期待は、未だかつてないほど高まっています。
創業間もない頃、（多くの SaaS 企業のように）Flywheel も単一ティアの VM ベースのプラットフォームとカスタム オーケストレーション ツールを構築していました。始めはこのアプローチがうまくいきましたが、Flywheel が成長するにつれ、運用上のオーバーヘッドの多さ、頻発するメンテナンスのニーズ、低いリソース使用量、そして強い結合によるアジリティの欠如を経験するようになりました。
そして、新機能や新商品に関する顧客サポートではなく、すでに構築したものへの対応に多くの時間を費やしていることに気がつきました。また、プラットフォーム内のデータの大規模な分析を行う能力にも欠けていました。運用上のオーバーヘッドが少なく、顧客のニーズを受けて素早くシフトできるアジリティのプラットフォームに進化する必要があることは明白でした。
そこで、アーキテクチャのリエンジニアリングの一環として、Google CloudでGoogle Kubernetes Engine（GKE）、Filestore、Cloud SQL そして BigQuery をテストしようと決めました。すぐにいくつかの重要な利点を発見し、パフォーマンスの改善、より優れた費用管理、必須のスマート アナリティクス機能の獲得が可能になりました。
リソース効率に優れた Kubernetes アプリ: GKE のリソース使用量には非常に驚きました。90% を超える CPU 負荷でノードが実行できるようになったことにより、未使用のリソースが 85% 減少ししました。加えて、GKE では問題なくこのレベルでノードを確実に実行し続けることができました。以前のプロバイダは、高い CPU 負荷に VM が耐えられず、頻繁にアクセスできない状態になっていました。
高パフォーマンスでフルマネージドのファイル ストレージ: Filestore は、GKE と統合されたフルマネージドの NoOps サービスです。そのため、自分たちで運用していなくても、顧客のニーズに応じてファイルシステムを簡単に拡大または縮小できます。
MySQL 用のフルマネージド リレーショナル データベース サービス: Cloud SQL であれば、パフォーマンスや可用性を損なうことなく、容易にデータベースをスケールできます。また、メンテナンス費用も大幅に削減されました。
サーバーレスでスケーラビリティの高い、優れた費用対効果のデータ ウェアハウス: BigQuery のデータ分析能力、そして数回クリックするだけで結果を共有できる能力に満足しています。BigQuery を新しいアーキテクチャに統合することにより、必要とするスマート アナリティクス機能を、運用上のオーバーヘッドがゼロの状態で利用できます。
GKE のリソース使用量と信頼性の向上を活用し、さらにいくつかのマネージド サービスを実装して、すべてのティアを自分たちで運用する手間を省きたいと考えていました。しかし、そのためにはアーキテクチャに簡単な変更を加える必要がありました。
コンテナベースの多層アプリケーションの構築
まず、軽量のコンテナを使用するためにアーキテクチャを再設計しました。これには膨大な手動のリファクタリングが必要であることがわかっていたため、最初から正しい方法で行いたいと考えていました。コードを書き始める前は、このアーキテクチャの設計と検証に協力してくれた Google Cloud のチームに頼り切っていました。クラウド ネイティブ ソフトウェアの開発、運用に対する Google の専門知識は、Google をパートナーとして選ぶ上での重要な差別化要因でした。この強力なパートナーシップと緊密なコラボレーションを通して、適切な戦略の構築、実行ができ、さらには望ましい成果まで上げることができました。
こうした設計上の決定は、コンテナベースのアプリケーションのリソース利用の促進が発端でした。VM ベースのプラットフォームでは CPU アイドルが非常に多く残されていて、85% に達する場合もありました。コンテナベースのワークロードを GKE 上で実行することで、平均 30% しかなかった CPU の使用率が、90% へという、200% もの増加を見せました。
そこからは、簡潔さを心掛けるというソフトウェア エンジニアリングにおける特に重要な原則の一つに従いました。Flywheel の目標は、プラットフォーム上のすべての WordPress サイトが最大のパフォーマンスと信頼性で運用できるようになることです。そのために、3 つの Google Cloud サービスを主に使用しました:
ファイルシステムを管理する Filestore
データベースを管理する Cloud SQL
クラスタの自動スケーリングと、コードを実行するためのクラスタ マルチテナンシーが有効になった GKE
新たなアーキテクチャには多くのコンポーネントがありましたが、マネージド サービスを選んだので、チームに追加のオーバーヘッドは発生しませんでした。Flywheel がサイト パフォーマンスの最大化という目標の達成に集中する一方で、Google Cloud はサービスの信頼性とスケーラビリティにフォーカスしています。Google Cloud Console UI、REST API または Cloud SDK を通して、顧客のニーズに応じて簡単にコンポーネントをスケールアウトまたはスケールインできます。これにより、チームがプラットフォームの管理と運用を行う上で必要とする柔軟性と制御が得られるようになりました。
BigQuery の役割
コア プラットフォームが設計され、GCP での運用が始まった後は、迅速な分析のためにプラットフォームから BigQuery へデータのフィードを開始しました。もしシステムにパフォーマンスのボトルネックがあれば、即座に特定し、修正できます。もし顧客が未使用のリソースを保有していれば、ハイライト表示し、効率の改善につながる方法を推奨できます。このようなプラットフォーム内のデータから得た新たな発見により、市場の動向や顧客のニーズに対応する際に必要となるアジリティが備えられるようになりました。
最後に
振り返ってみると、カスタム プラットフォーム、カスタム オーケストレーション ツール、カスタム コンポーネントを維持するための手動作業を省くことができ、新商品や新機能に関する顧客サポートにより多くの時間をかけられるようになったため、このプロジェクトは非常に有益でした。顧客の目的は読み込みが早く確実なウェブサイトを簡単に公開することで、新たなアーキテクチャの少ない運用上のオーバーヘッド、頻度の低いメンテナンスのニーズ、リソース使用量の増加、スケーラビリティの改善がその目的の達成に役立つことになりました。
Flywheel が Google Cloud を選んだ理由は技術の素晴らしさというだけではなく、スケーリングに不可欠な要素に対するチームの独自の知識でした。Google には、それぞれ 10 億人以上のユーザーがいる 9 つの製品があり、ピーク パフォーマンスを実現するための専門知識を提供できる独自の立場にあります。Google チームとの協力的なパートナーシップが、この重要な戦略的取り組みを成し遂げるための指針となりました。
この投稿でハイライトした Google Cloud ソリューションを実際に体験するための、無料トライアルにぜひご登録ください。
-Google Cloud エンタープライズ カスタマー エンジニア Micah Knox
-WP Engine プラットフォーム エンジニアリング担当バイス プレジデント Charles Wagner
