メインフレームの移行が単なるテクノロジーの変革ではない理由

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

英国の作家であり小説家の L.P. Hartley はかつて「過去とは異国のようなものだ。今とは物事の進め方が違う」と言いました。メインフレームの移行という領域において、この感覚は特に当てはまります。メインフレームの移行はしばしば組織全体に予期せぬ変化を引き起こします。

メインフレーム環境で確立しているプロセスは、メンテナンス、セキュリティ、サポートなどの重要な機能を備えた、一元管理型の内部サービスとして提供される傾向があります。しかし、アプリケーションやワークロードをクラウド環境に移行する際は、このような一元化されたプロセスや提供方法も変えなければなりません。

デリバリーを一元管理することは、整合性、エンジニアリング リソースの共有、一括割引、組織の要件の専門的な理解の向上につながり、費用削減に効果的であることが実証されています。一方でリソースが有限であることがスケーラビリティ、柔軟性、迅速な処理の妨げになり、メインフレームに少しでも関わるイニシアチブはすべて一元的に調整しなければなりませんでした。

しかし、クラウドへの移行が完了に近づく頃、多くの組織は突如として、かつてメインフレーム チームが行っていた作業を再現する必要があることに気づきます。とはいえ、この頃には変更に対応できる新たな力を手に入れています。このように、変革がもたらすメリットを組織が最大限に活用しようとする際に非常に役立つのが、クラウド プロバイダやパートナーの深い専門知識です。

Google Cloud コンサルティングでは、組織が複雑な移行を遂行するのを何度も支援し、変革はテクノロジーだけでなく、人やプロセスにも関わるものであることを目の当たりにしてきました。この投稿では、メインフレームからクラウドに移行する際に大きな影響を受け、変化することが予想される 3 つの分野をご紹介します。

メンテナンス: 違いは設計にあり

私たちはよくお客様に対し、新しいクラウド チームに余計な負担をかけないようにするため、プロセスが不要になる設計にすることをおすすめしています。たとえば、AlloyDB、CloudSQL、BigQuery といった Google Cloud のマネージド データベースを使用すれば、オンプレミスのデータベースやデータストアに関連するユーティリティやメンテナンス タスクの多くをなくすことができます。毎晩のバックアップや毎年のデータベース再編成などのプロセスが Google Cloud によって自動化、管理されるため、心配する必要がなくなります。

同様に、Google Cloud では、GKE インスタンスを定期的（30～45 日間隔など）にローテーションすることにより、OS のアップグレードとパッチを自動的に実行できます。組織はこれをポリシーで定義し、新しい OS イメージのロールアウトを CI / CD パイプラインに統合できます。こうすることで、これらのプロセスはモニタリングや管理を必要とする個別の作業ではなく、通常の開発ライフサイクルの一部となります。

当然ですが、それでもバックアップや緊急の復元プロセスは定期的にテストする必要があります。とはいえ、テストは特に面倒なものではありません。組み込みのネットワーク分離機能とオンデマンド容量を組み合わせれば、障害復旧環境をスピンアップし、データベースを復元してテストを行い、再び停止させることが十分可能です。しかも、これらはすべて本番環境を停止させずに実施できるのです。

移行する前の一元化されたプロセスと比較して、クラウドベース アプリケーションでは、メンテナンスと更新にかかる労力と時間を、オンプレミス ソリューションで同じタスクを行う場合よりも大幅に削減できます。

セキュリティ: 全員が鍵を持つ（とは限りませんが）

移行時に課題となることが多いものの一つが、セキュリティへの対応です。Google Cloud はデフォルトで保存データの暗号化を提供していますが、それだけでは必ずしも十分ではありません。鍵のローテーションなど、追加のステップを検討する必要があります。クラウド環境に移行するにあたり、鍵をローテーションすることは組織の責任となります。

メインフレームについては許容される最低限のソリューションでよしとしてきたかもしれませんが、クラウドへの移行を機にセキュリティ管理を強化しようとする組織は少なくありません。そのため、新たな負担が生じる場合があります。メインフレームでは、すべてのデータに対して同じ鍵が使われる可能性がありますが、クラウドの場合、すべての場所ですべてのデータに同じポリシーを適用することは非論理的です。

成功するパターンとしてよく見られるのは、各プロダクトやアプリケーションのオーナーに鍵をローテーションする責任を持たせる方法です。こうすることで、データに応じて異なるローテーション ポリシーを設定できます。たとえば、最高レベルの PCI および PII 保護が必要なデータの鍵は 90 日ごとにローテーションし、一般公開データは 12 か月ごとにローテーションします。このパターン化により、鍵が漏洩した場合の影響範囲も小さくできます。目標は、データや各地域の法律に合わせてポリシーを調整し、わずかな労力で全体的なセキュリティ対策を向上させることです。

同様に、クラウド コンプライアンスも対処すべき極めて重要な課題です。コンプライアンスの監査には時間がかかりますが、組織が透明性を確保し、データとクラウド アセットを保護するうえで非常に重要な手続きです。監査を成功させるコツは、コンプライアンスを示す電子証跡でポリシーとドキュメントを裏付けることです。クラウドの優れた点は、既存のクラウド ドキュメントに組織のポリシーを適用したり、要件を満たしていることの証明としてプロダクトやサービスのログを使用したりするのが容易なことです。

サポート: 新たな責任、より優れたソリューション

午前 2 時にかかってくる電話ほど嫌なものはありません。何かが失敗したか（よくないこと）、うまくいっていない（さらによくないこと）からです。メインフレームは緊密に統合されているため、サポートは主に、メインフレームの問題をゼロからトラブルシューティングするスキルとセキュリティ権限を持つ、オンコールのコアチームに任されていました。

Google Cloud に移行すると、Google がインフラストラクチャを提供する責任を担いますが、何が実行されているかは Google ほとんど把握していません。そのため、サポートは個々のプロダクト チームが担当することになります。新しい責務ですが、Google Cloud から多くのサポートをご提供します。

Google Cloud Operations には、トラブルシューティングに役立つ完全に統合された指標一式が一括表示されるため、問題点を簡単に見つけることができます。これらの指標は、組織の特定の技術スタックを反映するようプラグインで最適化することができます。

さらにクラウドは、夜中に電話でデバッグする必要のない問題を解決するための新たなオプションも提供します。たとえば、問題が発生したインスタンスをクラスタから隔離し、数秒で代替インスタンスをスピンアップすることも可能です。その結果、お客様の生活に支障をきたすことなく、チームは朝、コーヒーを飲みながら問題を解決できるようになりました。

最後に

メインフレームの移行に着手することは、大変であると同時にやりがいもあります。新しい役割や責任を担うことはエキサイティングなことですが、何十年もかけて特定の役割のスキルを磨いてきた既存のチームにとっては、大変な移行になる可能性が高くなります。組織は、このことを前提としてそれに応じた計画を立て、設計と自動化を通じて可能な限り問題を排除する必要があります。

Google Cloud コンサルティングは、このプロセスの複雑さを理解しています。Google のチームは、深い専門知識を活用して移行を効率化し、プロセスを自動化して、組織がクラウドの可能性を最大限に活用できるようにすることで、お客様がこのような変化に対応できるよう全力でサポートします。

メインフレームのモダナイゼーションに対する Google Cloud の取り組みについて詳しくは、こちらをお読みいただくか、Google Cloud のエキスパートにお問い合わせください。現在受付中: Google Cloud コンサルティングにご連絡ください。どうすればお客様の組織固有のニーズや目標に合わせた移行戦略を策定できるか探りましょう。Google と連携することで、メインフレーム移行という課題を成長とイノベーションの機会に変えることができます。

-Google Cloud コンサルティング、メインフレーム リード David Morley