Google Cloud Platform: ITインフラストラクチャーのモダナイゼーション -マルチクラウド、クラウド選定、ベンダーロックインを考える (後編)
2020/06/24
テクノロジーコンサルティング本部 Dataグループ シニア・マネジャーの青柳雅之です。私はデータやアナリティクスの領域を中心にAWS/Azure/GCPといった各パブリッククラウドにおける業務に従事しています。
お客様からは「新しいビジネスに柔軟に俊敏性を持って対応し、安定性の高いITインフラストラクチャーを構築したい」というご要望を聞くことが多いです。今回のブログでは、このようなご要望に関して主要な論点を選び、ITインフラストラクチャーのモダナイゼーションに関するポイントについて解説します。筆者はAccenture Google Cloud Business Group ソリューションアーキテクトも兼任していますので、例としてGCPのサービスを掲載させていただきますが、基本的な考え方自体は他のパブリッククラウドでも通用するものです。前編に引き続き、この後編では、コンテナによるベンダーロックインの可否、メインフレームのクラウドへの移行に関する論点を解説します。
- コンテナはベンダーロックインを回避する技術として有効か
ベンダーロックインを回避するもう１つの方法として、コンテナを検討する場合があります。
コンテナとは、OS上に論理的に境界を作る技術であり、その中でお互いに独立したアプリケーションが稼働します。このコンテナが稼働するためのコンテナ型仮想化技術ではDockerが有名です。１つのOSで1つのアプリケーションを稼働させるよりも、コンテナ内にアプリケーションを保持した方がOSの上に複数のコンテナ、つまりアプリケーションを配置でき、結果的にハードウエアのリソースの有効活用が可能となります。そして、アプリケーションの起動は仮想化技術上のOS(仮想マシン)を起動するよりも高速です。
図：コンテナ
また、コンテナが増加し、コンテナが稼働するサーバーの台数が多くなる場合、これらのサーバーをまたがってコンテナを配置したり（例えば、稼働率の小さいサーバーに優先的にコンテナを配置します）、起動、停止したりする管理的作業を行うためのツールが開発されました。これをオーケストレーションツールと言います。Googleがオープンソースとして開発・公開したオーケストレーションツールがKubernetes(K8s)です。そして、KubernetesをGCPでマネージドサービス化したものがGoogle Kubernetes Engine、GKEとなります。同様のサービスとしてはAzureではAKS、AWSではEKSがあります。
必ずしもすべてのアプリケーションをコンテナ化する必要があるかといえば、そうではありませんしそもそも技術的に難しい場合があります。組織の中のアプリケーションでコンテナ化可能な比率が高い場合、コンテナはベンダーロックインを避ける技術としては有効な技術かもしれないですが、その比率が低い場合はその限りではありません。そして、実際には多くの組織では、コンテナ以外に、サーバーレスも仮想マシンも併用されていることでしょう。また、特にオンプレミスからクラウドに移行する際はいきなりコンテナにせず、移行に際して変更の少ない仮想マシンなどを検討することも忘れてはいけません。最初はこれらのサービスを利用し、クラウドの知見を上げてから要件によってはコンテナも視野にいれるという段階を踏んだほうがより早くクラウドに移行できるでしょう。コンテナの大きなメリットは、ベンダーロックインというよりも、よく知られているように、すでに複数のクラウドやオンプレミス環境があり、それらで同一のアプリケーションを稼働させたい場合、テスト環境、本番環境への移動が容易なこと、アプリケーションの高速なスケーリングがしやすい、開発がコードベースで行える、というところでしょうか。
ここでGCPが提供するAnthosを紹介します。オンプレミス、マルチクラウドの環境で一元的にGCPの管理コンソールからコンテナを管理できるサービスです。AnthosはKubernetes Engine（GKE）と、サービスメッシュ（サービスを提供するコンテナの集まりと考えます）管理のIstio、その他OSSをベースとした様々な機能で構成されているコンテナの実行、管理基盤です。また、Migrate for Anthos は、仮想マシンをコンテナに変換する機能を提供しており、なるべく多くのITリソースをコンテナ上で稼働させるためのツールがそろっています。コンテナを稼働させるための異なる環境があり、多数のコンテナがその上で稼働する状況であれば、Anthosは有効な選択肢になるでしょう。
図表：Anthosの構成
- メインフレームのクラウドへの移行はどのように行うか
通常、移行評価を実施する際に、ビジネスインパクトと移行難易度でマイグレーションを行うリソースの優先順位付けを行います。この枠組みの中では、ビジネスインパクトが大きく、移行難易度が低いリソースの移行を優先します。メインフレームは移行難易度が高いと考えられており、移行について課題感を持っている組織も多いことでしょう。
メインフレームの移行には様々な移行の選択肢があります。
図：プランニングの進め方
これらの手法を実現するには多数のツールが活用できますが、Cornerstoneはそのうちの１つのツールです。2020年2月に、Google社は、オランダのメインフレームからパブリッククラウドへの移行サービスを提供するCornerstone Technology社を買収しました。Cornerstone のツールは、自動化プロセスを利用することで、COBOLや PL/1、Assembler プログラムをサービスに分割し、それらをマネージドコンテナ環境などでクラウドネイティブ化することができます。しかし、元のソースコードの依存関係や構造が複雑は場合は変換に手がかかることが多いと想定されます。実際には現行の状況をきちんと調査の上、移行コストの見積もりやツールの選定を行うべきでしょう。
弊社のAMO（Application Modernization & Optimization)というチームでは、メインフレーム等のレガシー・システムのモダナイゼーションを主に手掛けており、多くの実績を有しています。移行先のクラウドはGCPに限定しません。詳細はこのwebページを参照ください。
■GCPの導入をどう考えるか
GCPについては、今後はIaaSマイグレーションも増加すると思われますが、これまではビッグデータ分析やAI系のサービス、新規アプリケーション開発からGCPを導入するケースが多かったと見受けられます。前編で「クラウドの選定はどう考えるか」では６つの基準を示しました。この考えを適用すると、すでにこれらの領域でGCPの導入を他のクラウドに先駆けて完了している場合、オンプレミスにある他のシステムの移行先として、まずはGCPでFit&Gap分析を行うことになります。その上で別のクラウドを入れる際のメリットや、レディネスや運用の新な負担等のデメリットを材料に多角的な検討を行います。検討の結果、そのままGCPを拡大するか、領域によっては他のクラウドを導入するかの判断を行います。これは他のパブリッククラウドにも言え、すでに何かしらのパブリッククラウドを入れている場合は、同様の考えで検討するとよいかもしれません。
今回の前編、後編のブログでは、ITインフラストラクチャーのモダナイゼーションに関する論点について解説しました。
■参考文献
Docker/Kubernetes 実践コンテナ開発入門 山田明憲著
Cloud OnAir Anthosで実現するハイブリッドクラウド ～GKE On-Prem編 ～
アクセンチュア、国内で基幹系レガシーシステム刷新に向けた支援体制を強化
オンプレミスから GCP への移行の概要
