1. リサーチ事業環境
リサーチ業界に置いて国内No.1シェアのプラットフォームサービスを提供するマーケティングアプリケーションズ社。クラウド型サーベイツールと大規模な消費者パネルをもち、数多くの消費財メーカーや広告代理店の調査案件を支援してきた。国内でもユニークなビジネスモデルとデジタルプロダクトの開発を行っており、同社のエンジニアリングチームはリサーチ需要の拡大に伴って急速にリサーチプラットフォームの機能開発を継続して行ってきた。この数年でサーベイ対象となる消費者パネルデータは6倍、オンライン調査での配信規模は実に15倍にも拡大し、ビジネス環境は順調な成功を遂げてきたのである。
一方でビジネス需要における機能要件は満たしてきたものの、急速な事業拡大と機能開発においてオンプレミスで構築していたプロダクト群がパフォーマンスを満たさなくなり始めていた。CTO の猪狩氏はその状況を以下のように語った。
大規模な調査案件であれば時期を分散してキャパシティ調整を促すようビジネスサイドに注文せざるを得ないなど、ビジネスのスケールアップにシステム基盤が適さなくなってきたのです。(猪狩氏)
そこでエンジニアチームはプロダクト基盤をオートスケーリングできる環境へ全面移行することを決断。アプリケーションは大きく改修せず、Google Cloud Platform を軸に Kubernetes によるオーケストレーション環境を採択したのである。移行対象となるサーバー台数は100台前後、アプリケーションは大きな改修なくリフト、6ヶ月以内の移行プロジェクト完了を狙った。
2. クラウド移行に伴う課題
クラウド移行をスケジュール通り完了させるために課題となったのが、以下2つである。
- システムのキャパシティ性能とパフォーマンスを移行前後で比較できるベースラインの計測が必要であったが、OSS では Kubernetes 環境を可視化・計測できない
- 障害やボトルネック解消対応にかかっている運用工数を削減し高速化
1はそもそもキャパシティ上の問題を引き起こさないことが目的であった。実際の移行プロジェクトを担当する一海氏は以下のように話す。
負荷試験の実施において、現環境のパフォーマンスと、移行後の環境のパフォーマンス性能を比較できるベースラインを計測する必要がありました。オンプレミス環境では ZABBIX によるインフラ監視ツールを利用していたのですが、そもそも移行先となる GCP + Kubernetes 環境を計測することができなかったんです。特に障害の再現性の確保や原因特定に向けて1日がかりでの作業となりエンジニアリングリソースの生産性向上が課題となっていました。(一海氏)
3. 課題解決に向けたアプローチ
エンジニアリングリソースの解決には、論理上は「リソースの追加」という判断ももちろん存在する。しかし現代の日本市場においてエンジニア不足も深刻化しており、リソースの追加ではなく、生産性の向上という手段を取る必要があり多くのツールの検証が行われた。検証に上がったのはクラウド移行前まで利用していた ZABBIX などの OSS で監視スタック構築をする方法、 Saas型のインフラ監視ツール (D社)、そして New Relic である。この導入検討に当たっては大きく3つのカテゴリとして、機能、非機能、コストの観点を中心に検証が行われ、以下のような評価となった。
■機能 (監視能力や保守工数)
NR: ◯ 最新環境に対応、初期設定で調査分析の簡易化も可能
D社: X 最新環境に対応、監視対象の手動設定が必要
OSS: X 最新環境に一部対応、手動設定が必要
■非機能 (導入容易性やサポートレベル)
NR: ◯ 日本語ドキュメント及び日本語サポート
D社: △ 日本の事業所からのサポートが十分ではない
OSS: X なし
■コスト (課金体系)
NR: ◯ 自動課金ではなく利用料の急増=課金の急増にならない
D社: X 自動課金で毎月請求額が大きく変動する
OSS: X 無料だが保守工数コストが逆に増加する
検証結果において New Relic がマーケティングアプリケーションズ社の状況とマッチした部分について一海氏は以下のように語る。
新たな運用工数を増やすことなく、大きな生産性の向上が図れると判断できたのが大きかった。 (一海氏)
4. 課題解決後の影響
大きな工数増加なく Kubernetes 環境におけるアプリケーションとインフラのパフォーマンス低下や障害原因をコードレベルで可視化することに成功したマーケティングアプリケーションズ社は、クラウド移行後の障害対応やボトルネック改善のための調査にかかる工数を50%削減することに成功した。エラー率と発生箇所、レイテンシは低いが総量が多い箇所、トラフィックの集中やリソースの利用状況などをリアルタイムにメトリクスで捉え、コードレベルまで特定できることが可能になった為である。しかし New Relic の本当の価値はそこではないと猪狩氏は語る。
Kubermetes 環境とアプリケーションパフォーマンスがつながりを持って可視化できることで、エンジニアチームは単なる ”サーバーの死活監視” から ”サービスの信頼性監視” の視点に進歩することができました。これはビジネスサイドへ妥当性を持った意思決定を行えるようになったことと同じです。(猪狩氏)
現在猪狩氏は、New Relic 上でお客様単位でより詳細にパフォーマンスを確認できるようなダッシュボード構築を進めている。
サービスがオブザーバビリティを得ることでエンジニアがデータに基づいて性能や機能を改善し、デジタルビジネスの信頼性を高めていくことが必須となる時代が来ています。マーケティングアプリケーションズはすでにその一歩を踏み出し、新たな時代の変革をリードできると確信しています。(猪狩氏)
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.