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との適合性、災害復旧、クラウド環境の構築・運用スキルといった事項も考慮した上で判断していく必要があります。

クラウド移行コンサルティングと戦略アドバイザリーサービス

  • クラウド運用成熟度評価
  • アーキテクチャ評価
  • コンプライアンス基本方針の見直しと遵守
  • 課題の特定とリスク低減措置の検討
  • コスト及びキャパシティ最適化実現性の査定
  • 目標とするあり方に向けたロードマップの策定

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

クラウド適合性分析

アプリケーションの特定サーバー、ソフトウェア、ネットワーク機器、ストレージ

Right Arrow
Down Arrow
Left Arrow

依存性マッピングソフトウェアの依存性、サーバー・ストレージ間の関係性

Down Arrow

リスクアセスメント移行済みアプリケーション向けのソフトウェアライセンスモデル、セキュリティとコンプライアンス遵守

Right Arrow
Down Arrow

優先順位付けアプリケーション移行の順序立てと計画策定

お客様がクラウドに移行するアプリケーションを特定するお手伝いをするにあたり、当社が提案するのはクラウド適合性分析です。クラウド適合性分析の実施は、状態レベルの作業を通じて、アプリケーションを複雑性と移行適正に応じて分類することを目的としています(アプリケーションの認識とグループ化)。一番初めに移行するグループは、複雑性が低く、適性が高いアプリケーションで構成されます。一方、より複雑性の高いアプリケーションは移行フェーズの後期までキープしておくことができます。

一般的にアプリケーションの複雑性はその性質や他のアプリケーション、サーバへの依存度によって決定されます。中でも依存度の低いアプリケーションは移行が比較的容易です。同様に、お客様の事業や顧客にもたらす影響が少ないアプリケーションほど容易に移行が可能です。また、消費するリソースが少ないアプリケーションの移行もより早く行うことができます。インフラのコスト低減や未達成SLAを減らすためにも、多様な用途をもつアプリケーションは早期に移行する計画を立てることを推奨します。

移行の初期フェーズに適したもの

  • 開発環境、ステージング環境
  • 災害復旧ソリューション
  • 人材管理アプリ、内部ユーザ用のアプリ
  • サービス指向アーキテクチャを持つアプリケーション
  • 動的ワークロード(作業負荷)をもつアプリ

業務上必須であるアプリケーション、外部ユーザから接続可能なアプリケーションの移行は後期に回して良いと考えられます。移行するクラウド環境用にアプリケーションの書き換えが必要な場合、またマイクロサービスアーキテクチャを使ったアプリの再構築を計画している場合、所要時間を考慮して後期の移行が推奨されます

以上をまとめると、クラウド適合性分析の実施で、組織がアプリケーションを移行する際の明確性と方向性を示すことができるのです。大規模なポートフォリオを抱える大企業の皆様については、当移行プロジェクトを成功させるため特に慎重な順序立てが求められてきます。

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

Cloud Platform

クラウドに移行するアプリケーションの特定と同時に必要なのが、展開先のプラットフォームを考えることです。この決断においてセキュリティ、互換性、ツーリング、コストモデル等すべてが正当な判断材料となります。

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

他方、厳格なデータポリシーを追求する組織、政府機関、金融系企業、メディア・報道機関に適しているのがプライベートクラウドです。プライベートクラウド環境は専有リソースを活用した柔軟性、セキュリティの高さ、制御性の高さを特徴とし、業務上必須なアプリケーションのホストに適しています。

ここでパブリッククラウドとプライベートクラウド両方を同時に運用することをハイブリッドクラウド環境と呼びます。ただしパブリッククラウド環境に移行できるアプリケーションには限りがあります。一方、レガシーアプリケーションはプライベート環境にてオンプレミス又はコロケーションデータセンターでホストします。あるいは、プライバシー環境でホストするアプリケーションをパブリッククラウドに分散させ(クラウドバースト)、必要に応じてリソースの追加分を組み込むことも可能です。

多くの組織では価値提案とトレードオフを念頭に、複数のクラウドプラットフォームを活用する傾向にあります。マルチクラウドアプローチでは、お使いのアプリケーションを一つ以上のパブリッククラウドプロバイダ、あるいはプライベートクラウドに展開することが可能です。異なるプロバイダの元で複数環境を利用する場合、ベンダーロックインのリスクは低減され、お客様独自のニーズや作業負荷に応じてプロバイダを柔軟に切り替えることが可能です。

シングルクラウド戦略

  • すべてのアプリケーション/サービスを単一プロバイダで提供させる
  • 使えるサービスがプロバイダの提供範囲に限られる
  • クラウドAPIは一種類の習得で、比較的維持が簡単
  • ベンダーロックイン問題あり

マルチクラウド戦略

  • 異なるプロバイダが提供する複数のクラウド環境上でアプリケーションを実行させる
  • 作業負荷要件に合わせてプロバイダを選択できる
  • 熟練のITチームを必要とする複雑な戦略
  • プロバイダ間を容易に移行できる

「どのように」: 様々な移行方式

三つ目に検討すべき点となるのがクラウド移行をどのように行うかという問いです。ここでは、一つのデータセンターやプラットフォームから別のものへ移行を検討している多くの企業が一般的に採用する移行方式をご紹介します。

リフト&シフト(リホスト)方式

オンプレミス環境からクラウドへの移行を最も簡単かつ低コストで行える方式。その名の通り、コード変更をせずにお使いのアプリケーションをそのまま移行するやり方です(シャロ―クラウド統合)。オリジナルそのままのアプリケーション体験をクラウド上で再現し、オンプレミス環境でのセキュリティ体制を継続して利用できます。そのため、一瞬でリホストが可能です。ただしクラウドコストおよび性能については、後々最適化させる必要が生じる場合があります。

リホストを推奨するタイミング
  • クラウドコンピューティングが初めてでも、リホスト方式ならクラウド移行を簡単に実現できます。
  • オンプレミスインフラのコストを直ちにカットしたい場合、最も効果的なクラウド移行戦略です。
  • 中断や変更を加えずに稼働する必要があるアプリケーションをお使いの場合、リフト&シフト方式を検討することをお勧めします。
  • 災害発生時でも、アプリケーションをリホストすれば直ぐに起動、安定稼働を実現できます。スポットライト
特集記事

あるお客様は主要事業である人材採用ソリューションの需要が急増したため、高い拡張性とセキュリティを持つ堅牢なプラットフォームへのアプリインフラのクラウド移行を課題としていました。アプリケーションの稼働を中断することなく、早急に行う必要がありました。

そこで当社はAWSクラウド移行戦略を採用し、リフト&シフトアプローチの下、お客様のサーバ(ライブ採用ポータル、テストサイト、ブログサイト)をAWSプラットフォームに移行しました。フェイルオーバー機構とエラスティックコンピューティングを実装し、パフォーマンスの最適化とユーザ体験の向上を実現しました。全文を読む

クラウド・ネイティブ(再構築)方式

これはクラウド・ネイティブの伸縮性や可用性といった機能を活用したクラウド移行方式です。クラウドのフレームワークや機能性を最大限に活用いただくには、お使いのアプリケーションをリビルド、部分的にコードを書き換える必要がある場合があります。結果として時間とリソースを要するものの、成熟度の高いソリューションを実現することができます。このクラウド移行戦略では、完全移行前にカナリアデプロイで展開させ、問題が生じた際には旧設定にロールバックできる代替手段を利用することが可能です。 詳しく見る

リビルドを推奨するタイミング
  • 古く陳腐化が進んでいるアプリケーションを使われている場合、現状を維持するよりも一からリビルドする方が高い価値を得ることができます。
  • お使いのアプリケーションの拡張や機能の追加、パフォーマンス向上、事業継続性を高めたい場合、クラウド・ネイティブ方式でのリビルドをお勧めします。
  • サービス指向アーキテクチャ、もしくはマイクロサービスアーキテクチャに移行する用意がある場合も、この方式をお勧めします。
特集記事

あるお客様はクラウドにIoT処理のLambdaレイヤーを必要としていました。ソリューションは可用性が非常に高く、一日に複数のデプロイをサポートできる能力を兼ね備えていることが要件でした。ソリューション立案と並行して、お客様からはクラウド環境のアーキテクチャを構築してほしいという要望がありました。

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

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

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

クラウド移行方式として近年急速に人気が高まりよく利用されるようになったのが、コンテナ化戦略です。この戦略ではお使いのアプリケーションに必要なコンポーネント(アプリケーション、ライブラリ、設定ファイル)をまとめたコンテナを作成し、コンテナごとクラウドに移行します。コンテナを整理するのにコンテナオーケストレーション機構を活用しても良いでしょう。この手法では基盤となるOSやインフラからコンテナが抽象化されるため、別環境への移植性を担保することができます。 詳しく見る

コンテナ化が推奨される状況
  • お使いのアプリを速やかに別環境へ移行し、即時にスケーラビリティを持たせたい方には、コンテナ化をお勧めします。
  • 開発とテストに費やす時間を削減したい場合、コンテナ化は良い選択肢の一つです。
  • また、コンテナ化をすることでお使いのアプリケーションを複数の環境に分散させ、コストとパフォーマンスの最適化を実現できます。
特集記事

アルファフェーズを終えたあるお客様は、ソリューションをクラウドまたはカスタムデータセンターに移転する要望をされました。そこで私たちはそのソリューション用のDevOpsプラットフォームを設けました。そしてそのソリューションは、各サービスごとにDockerコンテナを持つマイクロサービスアーキテクチャを基盤に構築することにしました。これらのDockerコンテナをホスト・管理するためにKubernetesを使うこととし、コンテナをステートレスに保つために「Twelve-Factor」の方法論を採用しました。

このアプローチのおかげでソリューションのクラウドとデータセンター間の移行を簡単に行うことができました。さらに、ソリューションが構築されたシステムに依存することなく独立することを可能にしました。そして最も重要なことはコンテナをステートレスに維持したことで、安全に一日に複数のデプロイやロールバックを実行することができるようになったことです。

「どのように」: 様々な移行方式

三つ目に検討すべき点となるのがクラウド移行をどのように行うかという問いです。ここでは、一つのデータセンターやプラットフォームから別のものへ移行を検討している多くの企業が一般的に採用する移行方式をご紹介します。

比較クラウド移行戦略

リフト&シフト(リホスト)方式

短期間で簡単にできる 移行の後に再度最適化をする必要あり 変更を最小限に抑えられるため、最も低リスク 移行が容易にできる クラウド・ネイティブの恩恵なし 移行コストは最安であるものの、最適化の欠如により長期的なクラウドコストがかさむ可能性あり

クラウド・ネイティブ

複雑で時間を要する クラウドのフレームワークや機能性を有効活用できるように構築された堅牢なソリューション 変更箇所が多いため、高リスク ベンダーロックイン問題あり クラウド・ネイティブの機能性を最大限活用できる 移行にかかる短期的なコストは上がるが、長期的なクラウドコストは最小限に抑えられる

コンテナ化

クラウド・ネイティブ方式よりも短期間で実現可能 コードのみコンテナ移行されたものと、クラウド・ネイティブソリューションとして構築された残りのもの両方に対応する折衷案 コンテナの特長を上手く活用することで、はらむリスクを抑えることができる クラウド非依存である 拡張性のようなクラウドの基本的機能の恩恵を受けられる 短期的なコストは上がるが、長期的なクラウドコストは抑えられる

上記のものに加え、お客様のシナリオによっては次の2通りのクラウド移行戦略が適切な選択肢になることもあります。

リプレース方式

企業が商用オンプレミス型システムからSaaS型に移行することで目標を達成できることがあります。SharePointなどの多くのアプリケーションにはクラウドで実行できるアップグレード版が存在します。当社ではお客様のオンサイトCRMからSalesforceへの移行、SharePoint 2016/2013版からSharePoint Onlineへの移行といった移行サポートを行います。

リテイン方式

つい最近アプリケーションのアップグレードをされた方にとって、移行に向けた投資をする心構えがまだできていないかもしれません。そのような場合は現時点では現状を維持し、後々また再検討されても良いでしょう。また、すべてのアプリケーションがクラウド移行をすることで何らかの恩恵を得られるわけではありません。当社ではまずお客様のお使いのアプリケーションの評価を行い、移行する事業的価値が見いだせるものだけを移行するお手伝いをいたします。

を決定するクラウド移行戦略

アプリケーションをクラウドへ移行するのに唯一無二のソリューション、というのは存在しません。それぞれの方式に長所と短所があります。どの戦略を選択するかは、移行するアプリケーションとその基盤となるインフラの性質によって決定されます。

ある人は、厳密なAWSクラウド移行戦略よりもハイブリッドデプロイ型を選ぶでしょう。もしくはPythonベースのアプリをGoogleクラウドプラットフォームに展開しつつ、レガシーアプリケーションはプレミスで保持するのも良いでしょう。特定の運用方法では高度なクラウド統合が有益となりますが、シナリオによっては迅速なリフト&シフト方式が適する場合もあります。さらには、複数のアプリやサービスを移行する場合には、アプローチも複数採用しても良いでしょう。

私たちはお客様のクラウド移行をスムーズかつ成功に導くため、内包する複雑性、課題、コストを考慮に入れた移行計画をお客様と一緒に策定します。

Migration Strategy