Inquiry icon

START A CONVERSATION

Share your requirements and we'll get back to you with how we can help.

Thank you for submitting your request.
We will get back to you shortly.

クラウド移行戦略

企業の成長には、クラウドの導入は避けて通れないものかも知れません。しかし、データを従来のインフラからクラウドプラットフォームへ移行することは、途方もないことのようにも思えます。クラウドマイグレーションは複雑なものです。そのため、それぞれの組織のニーズに合わせて、プロセスをカスタマイズする必要があります。サービスへの影響を最小限に抑え、かつ短期的および長期的な組織目標の両方に対応するクラウドマイグレーション戦略が必要となります。

クラウドマイグレーションを行うにあたり、「何を」「どこへ」「どうやって」移行するのかということを明確にしなければなりません。

このような問いに対して有効に対応するには、アプリケーションとインフラの状態に加え、移行に向けたビジネスドライバーを詳しく調査することが不可欠です。データセキュリティ、規制の遵守、SLAとの適合性、事故からの復旧、そしてクラウド環境を構築・運用するためのスキルを考慮することも、意思決定に影響します。

クラウドマイグレーションのコンサルティングと、戦略的アドバイスサービス

  • クラウド運用の成熟度評価
  • 構造的評価
  • コンプライアンス基準の見直しと遵守
  • 課題の認識とリスク軽減オプション
  • コストおよび能力の最適化可能性の評価
  • 目標とする状態に向けたロードマップ策定

「何を」: 移行するアプリケーションを特定する

Cloud Fit Analysis

Application DiscoveryServers, Software, Network devices, Storage

Right Arrow
Down Arrow
Left Arrow

Dependency MappingSoftware dependencies, Server-to-storage relationships

Down Arrow

Risk AssessmentSoftware license models for migrated applications, Security and compliance

Right Arrow
Down Arrow

PrioritizationSequencing and scheduling apps

クライアントが移行するアプリケーションを特定するにあたって、通常は、クラウド適合性分析を提案しています。状態レベルの作業であるクラウド適合性分析を通じて、その複雑性と移行適性に応じてアプリケーションを分類することを目的としています(アプリケーションの発見とグループ化)。複雑性の低い、あるいは適性が最も高いアプリケーションは、最初に移行するものと特定されます。一方、複雑性の高いアプリケーションは、後の移行フェーズまで保存しておくことが可能です。

一般的に、アプリケーションの複雑性は、その性質や、他のアプリケーションやサーバへの依存性によって決定されます。依存性が低いアプリケーションは移行が容易になります。ビジネスや顧客にとって、最も影響が少ないアプリケーションも同様です。また同じように、使用するリソースが少ないアプリケーションほど、早く移行することができます。インフラのコスト低減や、SLAを見逃さないためにも、様々な用途のあるアプリケーションは早期に移行する予定を立てた方がよいでしょう。

移行の初期フェーズに最適

  • 開発とステージング環境
  • 事故復旧ソリューション
  • 人事アプリ、内部ユーザー用アプリ
  • サービス思考アーキテクチャを持つアプリケーション
  • 動的ワークロードを持つアプリ

必須アプリケーションや外部ユーザからも使用できるものは、後ほど移行できます。クラウド環境用にアプリケーションの書き換えが必要な場合、またはマイクロサービスアーキテクチャを利用してアプリを再構築する予定がある場合は、その手間を考慮して、後から移行する必要があります。

つまり、クラウド適合性分析は、組織がアプリケーションを移行する際に明確な方向性を示すことができます。大規模なアプリケーションポートフォリオを持つ企業は、移行プロジェクトを成功させるため、特に慎重に移行の順番を考える必要があります。

「どこに」: クラウドプラットフォームの選択

Cloud Platform

クラウドに移行するアプリケーションを特定する一方で、展開先のプラットフォームも考慮する必要があります。セキュリティ、互換性、ツーリング、そしてコストモデルは、すべてこの判断においては重要なものです。

AWSAzureGCPのようなパブリッククラウドへの移行は、ハードウェアやソフトウェアを購入することなく、オンデマンドでリソースを提供するため、人気の選択肢のひとつです。パブリッククラウドでは、サードパーティのプロバイダがリソースを所有、運営しており、テナント間で共有されることが多くなっています。

厳格なデータプライバシーを求める組織、政府機関、金融企業、メディアハウスなどは、プライベートクラウドを選択できます。専用のリソースを使用したプライベート環境は、柔軟性、セキュリティ、制御性が高く、ビジネスに不可欠なアプリケーションのホスティングに適しています。

ハイブリッドクラウド設定とは、パブリックとプライベート両方のクラウドを同時に運用する場合を指します。パブリッククラウドには、一部のアプリケーションしか移動できません。レガシーアプリケーションは、オンプレミスあるいは共同データセンターなどのプライベート環境でホストすることができます。また、プライベート環境でホストされているアプリケーションをパブリッククラウドにバーストさせ(クラウドバースト)需要が上昇した際に追加リソースに組み込むことも可能です。

多くの組織では、多数の価値提案に加え、トレードオフを考慮して、複数のクラウドプラットフォームを活用する傾向にあります。マルチクラウドのアプローチでは、アプリケーションを一つ、または複数のパブリッククラウドプロバイダやプライベートクラウドに展開できます。異なるプロバイダを利用する環境が混在しているため、ベンダーのロックインリスクが軽減されおり、特定のニーズやワークロードに応じてプロバイダを柔軟に切り替えることが可能です。

シングルクラウド戦略

  • すべてのアプリケーションとサービスを、単一のプロバイダで提供
  • 選択したプロバイダの提供範囲に限る
  • 一種類のクラウドAPIを習得すればよく、比較的維持が簡単
  • ベンダーのロックイン問題

マルチクラウド戦略

  • 複数ベンダーのクラウド環境からアプリケーションを実行
  • ワークロードの要求量に応じてプロバイダを柔軟に選択可能
  • 熟練のITチームを必要とする、複雑な戦略
  • プロバイダ間を容易に移動可能

「どうやって」: 移行方法

移行プロセスの「どうやって」の部分が、パズルの3つ目のピースです。データをデータセンターから、あるいはあるプラットフォームから別のプラットフォームへの移行を検討している企業の多くは、以下のいずれかの方法でデータを移行しています。

リフトアンドシフト(リホスト)

オンプレミス設定からクラウドプラットフォームへの移行を、最も簡単かつ低コストで行う方法です。その名の通り、この移行モードでは、コードに変更を加えずにアプリケーションをそのまま移行(シャロ―クラウド統合)させます。クラウド上でオリジナルアプリケーションが体験可能になり、オンプレミスで使用したものと同じセキュリティメカニズムを利用できます。その結果、素早く、あるいは限られた時間の中でもリホストの効果が期待できます。しかし、すぐにはパフォーマンスや、コスト面でもクラウドソリューションを最適化することはできません。

リホストするタイミング
  • クラウドコンピューティング初心者にも、リホストは簡単にクラウドへの移行ができます。
  • すぐにオンプレミスのインフラコストをカットしたい際にも、最も効果的なクラウドマイグレーション戦略と言えるでしょう。
  • 中断や変更を加えずに稼働する必要のあるアプリケーションに関しては、リフトアンドシフトを検討しても良いでしょう。
  • 事故の際、アプリケーションをリホストすれば、起動から安定稼働までを素早く行えます。
スポットライト

当社顧客の主要事業の人事採用ソリューションの需要が急増したため、そのアプリケーションのインフラを、高度に拡張性を持ちつつ、セキュリティ性の高い堅牢なプラットフォームに移行する必要がありました。アプリケーションの稼働を途切れさせずに、急いで移行する必要がありました。

当社はAWSクラウドマイグレーション戦略を採用し、リフトアンドシフトのアプローチから顧客サーバ(ライブ採用ポータル、テストサイト、ブログサイト)をAWSプラットフォームに移行しました。フェイルオーバーメカニズムとエラスティックコンピューティングを実装して、パフォーマンスの最適化とユーザー体験の向上を実現しました。全文を読む

クラウドネイティブ(再ビルド)

このようなクラウドマイグレーション方法では、弾力性や可用性など、クラウドネイティブの機能を活用します。クラウドのフレームワークや、機能を最大限に活用するには、アプリケーションを再構築したり、一部を再度コーディングする必要があります。プロセスに時間がかかり、リソースを必要ともしますが、結果として成熟したソリューションを提供できます。このクラウドマイグレーション戦略では、完全移行前にカナリアデプロイメントを実装し、問題が発生した場合には過去の設定にロールバックすることが可能な、フォールバックオプションを提供しています。 詳細

再ビルドのタイミング
  • アプリケーションが古く、陳腐化している場合、それを再構築する価値よりもメンテナンスのコストが上回ってしまいます。その場合、最初から作り直すのも一つの手段になります。
  • アプリケーションの拡張、機能の追加、パフォーマンスの向上や、事業の継続性を向上させたい場合、クラウドネイティブに再構築するとよいでしょう。
  • サービス指向あるいはマイクロサービス構造に移行する準備が出来たときに、この方法を使用することも可能です。
スポットライト

顧客にIoT処理のラムダレイヤーを求められました。可用性が高く、日毎に複数の展開をサポートできるソリューションが必要でした。ソリューションの開発と並行して、顧客からはクラウド環境のアーキテクチャを構築してほしいという要望がありました。

そのため、ELB、EC2、VPC、Subnet、RDS(Multi-AZ)やS3など、AWSのクラウド上で利用可能なサービスをベースに、可用性の高いソリューションを設計しました。ゼロからソリューションを構築するため、クラウドフォーメーションのテンプレートを作成し、インフラとして利用するスクリプトをコードとして維持しました。ソースコードの管理には、Gitflowワークフローを使用しました。Python、React、そしてJavaベースのアプリでは、環境間でコードを簡単に移動できるよう、Dockerイメージを作成しました。残りのSparkとScalaアプリについては、従来通りの展開手順を使用しました。

ツール内の各コンポーネントにAnsibleプレイブックを作成しました。このプレイブックは、環境内の各サーバで使用されているすべてのパッケージをインストールします。別のプレイブック一式では、コードベース(Dockerと非Docker)をそれぞれのサーバに展開します。最後に、Jenkinsを使用して、コードを引き出したり、各ソリューションを構築、そしてArtifactあるいはDockerのイメージをそれぞれ対応する環境に展開するためのトリガーとなる、カスタムジョブを作成しました。

コンテナ化(リファクタリング)

コンテナ化戦略は、近年急速に人気が高まり、利用頻度が上がったマイグレーション手法です。これは、必要なコンポーネント(アプリケーション、ライブラリ、設定ファイル)を束ねたアプリケーション用のコンテナを作成し、そのコンテナをクラウドに移行するものです。それらのコンテナを整理するには、コンテナの組織化機能が利用できます。この手法では、コンテナが基盤となるOSやインフラから抽象化されているため、移植性が担保されます。 詳細

コンテナ化するタイミング
  • アプリを別の環境に素早く移動させ、すぐに拡張性を持たせたい場合、コンテナを使用することでスムーズに行えます。
  • 開発とテストにかける時間を短縮したい場合、コンテナ化は良い選択肢だと言えます。
  • また、コンテナ化することによって、複数の環境にアプリケーションを分散させ、そのコストとパフォーマンスの最適化が可能です。
スポットライト

アルファフェーズが完了すると、ソリューションを顧客のクラウドまたはカスタムデータセンターに移行する必要がありました。そのため、このソリューションのためにDevOpsプラットフォームを作成しました。各サービスにDockerコンテナを使用したMicroservices構造をベースに、ソリューションを構築することにしました。これらDockerコンテナをホストしつつ管理するため、Kubernetesを使用することにしました。また、コンテナをステートレスに保つため、「Twelve-factor」の法則に従いました。

このアプローチにより、ソリューションをクラウドとデータセンター間で簡単に移行できるようになりました。また、ソリューションが構築されたシステムから独立していることも確保されました。最も重要なことは、コンテナがステートレスなので、エラーの心配もなく複数の展開やロールバックを行えるようになったことです。

「どうやって」: 移行方法

移行プロセスの「どうやって」の部分が、パズルの3つ目のピースです。データをデータセンターから、あるいはあるプラットフォームから別のプラットフォームへの移行を検討している企業の多くは、以下のいずれかの方法でデータを移行しています。

比較クラウドマイグレーション戦略の

リフトアンドシフト

短期間で容易に対応可能 後に再最適化が必要 変更が最小限なため、最も低いリスク 移行が容易 クラウドネイティブの恩恵はない 最低コストだが、最適化されないため、長期的なクラウドコストが増加する可能性有り

クラウドネイティブ

複雑かつ長期間を要する クラウド枠組や機能性が利用可能な、成熟したソリューション 変更が多いため、高リスク ベンダーロックイン クラウドネイティブにより機能を最大限に活用 短期コストは高くなるものの、長期的なクラウドコストは最小化

コンテナ化

クラウドネイティブのアプローチにより短期間で対応可能 コードのみをコンテナに移行し、他をクラウドネイティブソリューションとして構築する中間策 コンテナの特長をうまく使うことで、内包するリスクを低減可能 非クラウド依存 拡張性など、基本的なクラウドの恩恵有り 短期コスト高め、長期的なクラウドコストは低め

上記に加え、シナリオ次第では適切に成り得るクラウドマイグレーション戦略が2つあります。

リプレース

企業は、商用のオンプレミスシステムからSaaSシステムに移行することで、目標の達成が可能になる場合があります。SharePointなどの数多くのアプリケーションには、クラウドで動作するアップグレード版があります。当社は、顧客にオンサイトCRMからSalesforceへの移行や、2016/2013バージョンのSharePointから、SharePoint Onlineへの移行同等の移行サポートを行います。

リテイン

最近アプリケーションのアップグレードを行った場合、まだ移行に向けた投資をする準備ができていないかも知れません。そのような場合、ここでは現状維持を選択しつつ、後々にアプリケーションを再検討することができます。また、すべてのアプリケーションがクラウドマイグレーションの恩恵を受けるわけではありません。当社は、そのようなアプリケーションの評価をサポートし、移行する価値とその必要のあるものだけを移行します。

の決定クラウドマイグレーション戦略

クラウドへアプリケーションを移行することにおいて、一つの絶対的な答えというものはありません。それぞれのアプローチには、長所と短所があります。どのアプローチを選択するかは、移行するアプリケーションと、その基盤となるインフラの性質によって決定されます。

厳密なAWSクラウドマイグレーション戦略よりも、ハイブリッドな展開方法を選択でき、PythonベースのアプリをGoogleのクラウドプラットフォームに導入しつつ、レガシーアプリケーションはオンプレミスで保持することも可能です。ディープクラウドインテグレーションは、特定の使用例では有益ですが、その他の場合は、迅速な対応が可能なリフトアンドシフトのアプローチが良い場合もあります。複数アプリやサービスを移行する場合、アプローチも複数採用することもできます。

クラウドマイグレーションをスムーズかつ安全に行うには、その複雑さや課題、コストを考慮したマイグレーション計画をお客様と共に考えます。

Migration Strategy