変革の推進: Geotab が Google Cloud でアプリケーションをモダナイズする方法

※この投稿は米国時間 2020 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 最近の IDC Infobrief では、Google Cloud はアプリケーションの実行とモダナイゼーションに最適な「理想的なプラットフォーム」であると言われています。本日は、Geotab の DevOps 担当、アソシエイト バイス プレジデント、Patrick McClafferty 氏のお話をご紹介します。Geotab はフリート管理ハードウェアおよびソフトウェアの大手プロバイダです。同社がどのように変化を先取りして高まる需要に対応しているか、また稼働している約 1,600 台の本番環境サーバーをコンテナとオープンソースにモダナイズすることで、どのようにライセンス コストを削減しているかをお読みください。

Geotab は IoT とコネクテッド トランスポーテーションのグローバル リーダーです。車両をインターネットに接続し、行動につながるデータドリブン インサイトへのアクセスを提供することで、企業がフリートをより良く管理できるように支援することを、中核的な目標としています。Geotab のソリューションを通じて、車両のフリート生産性、最適化、規制変更へのコンプライアンス、安全性、持続可能性を向上させるために必要なツールをお客様に提供し、未来に向けてビジネスを推進できるように支援します。

私たちは大きな変化に直面している最中であり、今後もさらなる変化が到来すると、Geotab は考えています。電気自動車（EV）の普及に伴い、バッテリーの劣化、充電、温度に関する EV 特有の懸念事項が生じました。Geotab では、これらの事項に対する新たなビジネスニーズに対処するための、新たなソリューションを積極的に開発しています。また、将来的には、多くの OEM メーカーが自社工場に適したテレマティクス ハードウェアを導入することが予想されます。このため、Geotab は Volvo、Mack Trucks、General Motors、Ford などの企業と積極的に関わり、Geotab プラットフォームと Geotab マーケットプレイスに、サードパーティ製のハードウェアを使用せずにアクセスすることで、顧客のフリート管理機能を強化できるようにしています。

このような業界の傾向は、Geotab のすべての顧客が利用できるウェブベースのフリート管理ソフトウェアである MyGeotab プラットフォームにも変化が必要なことを意味します。Geotab は当初、カナダと米国のコロケーション施設においてオンプレミスでホストされていましたが、2015 年にパブリック クラウド オプションの利用を検討し始めました。最終的に Google Cloud をプライマリ クラウド プロバイダとして選択しました。試してみたさまざまなクラウド プロバイダの中で Google Cloud は最も安定性が高く、予定外のダウンタイムも最小限に抑えられるとわかったからです。Google Cloud のライブ マイグレーション機能は、再起動を必要とせずに VM インスタンスを新しいホストに移行でき、ワークロードをクラウドで確実に実行させるために特に重要な要素でした。また、モダナイゼーションを実現するための目標を達成できるように、Geotab のチームと協力して取り組んでくれるパートナーも探していました。Google Cloud は、今日のための、また未来に向けた最良の選択でした。

Geotab がオンプレミスから Google Cloud への移行を開始すると、ソフトウェアのライセンス コストが急速に上昇し始めました。MyGeotab は主に 1 つの言語で書かれ、1 つの開発フレームワーク上に構築されているプラットフォームです。また本番環境システム（顧客向けと社内向けの両方）のほとんどが、基盤となる 1 つのプラットフォーム上で稼働しています。さらに現在、MyGeotab 開発環境の大部分は、クラウドでプロビジョニングされた特殊な開発環境か、ノートパソコンなどのローカル コンピュータ機器のいずれかにある、同じプラットフォーム上で稼働しています。

クラウドへの移行は、Geotab の成長が急速に加速する時期とも重なりました。オンプレミスからの移行を開始した当初は、約 120 台の物理サーバーがあり、ホストごとに 1 台の VM を稼働させていました。現在では、1,600 台以上の VM インスタンスを Compute Engine 上で稼働させています。ライセンス コストは実行するコア数に比例して増減するため、この大きな成長に伴ってライセンスの総コストも自然に著しく増加しました。

新しい進路の設定

Geotab は Google Cloud の導入がうまくいくようになると、システムと運用の改善に役立つさまざまなサービスと機能を取り入れました。Geotab は多数のシステムで Cloud Load Balancing（TCP と HTTP/HTTPS の両方）を使用しています。コストとその管理方法を明確に理解するために、課金ラベルとレポートが役立っています。また、永続ディスク スナップショットと Cloud Storage を使用して、バックアップと DR 運用を管理しています。

MyGeotab をモダナイズするための長期的なプロジェクトに取り組み、独自のプラットフォームからオープンソースやコンテナに移行することも決定しました。この規模の本番環境ワークロードをまったく新しいプラットフォームに移行するのは大変な作業ですが、顧客やエンドユーザーに大きな混乱をもたらすことなく、1 つ 1 つの作業に取り組むことが可能です。この長期プロジェクトの主な目標は、顧客を最優先にしながら、よりコスト効率の高いビジネスモデルに移行することでした。

移行プロセスの開始にあたり、データベースの移行から始め、アプリケーションを独自のリレーショナル データベースから Postgres に移行しました。これにより、中断を最小限に抑えつつ、ライセンス コストを最大限に節約しました。最初に、カスタムの移行コードを開発し、Postgres との間で 1 つの顧客データベースを移行できるようにしました。

最終的には、1 つのデバイスのデータを Geotab のゲートウェイ サーバーから複数の顧客ポータルに同時にストリーミングする機能を追加しました。これにより、大規模な顧客のデータベースのバックアップを Postgres に移行し、データを Postgres と配信元サーバーの両方に同時に push できるようにしました。このプロセスにより、大規模な顧客の Postgres 用に MyGeotab を最適化することができました。その間も大規模な顧客の本番環境システムは、確立された非 OSS バージョンで稼働し続けていました。2016 年半ばまでには、最後の顧客データベースを移行し、MyGeotab 環境の 100% を Postgres 上で稼働させ、その結果、ライセンス コストは大幅に削減されました。

またオプションとしてさまざまなプラットフォームで稼働できるよう、MyGeotab を .NET コアに移行することも決定しました。ここでも、長期的なコスト節約を見込めたことが、この決定の主な動機となりました。

ごく最近では、アプリケーションをコンテナ化することと、Linux 上での実行を可能にするために、必要なサポートツールとフレームワークを構築することに焦点を移しました。まず、テスト環境と内部開発環境を移行して、なんらかの潜在的なバグやパフォーマンスの問題が本番環境で発生する前に、それらの問題に対処することから始めました。ワークロードのデプロイを簡素化し、カスタムの VM イメージの拡散を減らすことが、Linux ワークロードをコンテナで実行するための動機となりました。以前は、Geotab は社内の一意のサーバタイプそれぞれに対してカスタムの不変 VM イメージを作成し、毎月、更新されたバージョンのイメージで Compute Engine のすべてのインスタンスを再プロビジョニングしていました。Compute Engine のフットプリントが大きくなるにつれ、時間の経過とともに、一意の「ゴールデン イメージ」の数は増加していきました。

この拡散をうまく管理するために、Linux 戦略の開発時に調整を行いました。現在では、スタンドアロンの Compute Engine Linux インスタンスは、それぞれ一意のワークロードを実行する VM にデプロイされた Docker コンテナで同じベースイメージを実行しています。移行戦略の一環として、MyGeotab のデータベースとアプリケーション環境をコンテナ化するために必要な作業を行いました。また、CI / CD プロセスの一環として、これらのイメージに署名するために、Container Registry と Binary Authorization の脆弱性レポートも使用しています。現在、これらのコンテナは、Kubernetes などのオーケストレーション ツールを使用せずに、スタンドアロンの VM にデプロイされています。ソフトウェア コンポーネントや機能をメイン アプリケーションから切り離して、Google Cloud Kubernetes クラスタで実行するというのが、Geotab の長期戦略です。とはいえ、まだ初期段階です。

目的地に近づく

移行の第 1 段階はまだ進行中ですが、すでにライセンス料を大幅に節約することができました。移行のためにスケジュールする必要があるダウンタイムの増大に起因して、大規模な顧客は移行に少し時間がかかると予想されたため、第 1 段階では、Geotab デバイスが 1,000 台未満の小規模な顧客を対象としました。すべての顧客について移行が完了した後は、ライセンスとインフラストラクチャのコストが削減される結果、月間コスト削減が現在の 2 倍となり、MyGeotab プラットフォームでのソフトウェア ライセンス料の 50% 以上を節約できるようになると予測しています。

いかなる取り組みにも課題がつきものですが、今回の移行で最も大きな課題はデータベース側にあります。Linux 上の Postgres への移行に関わる各ステップで、独自の課題が一通り見つかり、カスタムの実装ツールを開発する必要が生じました。また、大規模なデータベースの移行でダウンタイムを最小化するにはどうすればよいかという問題もあります。大規模な顧客の多くは数十テラバイトのデータベースを稼働させており、場合によっては移行に 24 時間以上かかることもあります。この課題を解決するために、Geotab ではカスタムのツールを開発しました。このツールを使って、顧客が起動および稼働している間になおも大規模な移行を行い、移行の最終段階で顧客を停止させ、最初の移行からの差分をすべてコピーするようにしました。このカスタマイズされたアプローチにより、大規模な顧客の一部は、実際のダウンタイムをわずか数時間に抑えて移行することができました。

課題を抱えながらも、この取り組みは実を結びました。今では、より少ないダウンタイムでより多くのシステムを実行できるようになり、顧客は新機能にアクセスできるようになりました。この移行を受けて、Geotab は MyGeotab をアップデートして、常に進化し続ける環境との関連性を維持することがさらに容易になりました。何よりも、ライセンス コストの節約という具体的なメリットを享受しながら、これらすべてを行っています。Google Cloud と一緒にこの取り組みを続けられることを楽しみにしています。

-Geotab の DevOps 担当、アソシエイト バイス プレジデント、Patrick McClafferty 氏