クラウド移行のための 5R 方式のベスト プラクティスの概要

翻訳者 |チェン・ジュン

企画 |趙雲

近年、クラウド移行という言葉は、ほとんどの企業の IT に関する議論で頻繁に登場しています。当初、この用語は、ローカル インフラストラクチャ上のサーバーから AWS EC2 などのクラウド インフラストラクチャにサービスを移行する手法を指していました。今日では、クラウド移行の概念は、特定の負荷を処理するためにホストされたデータベース、API ゲートウェイ、さらには AWS や Azure への移行も含まれるように拡大しています。もちろん、金融業界や公共部門の企業の場合は、特別な規制要件を満たすプライベート クラウドまたはパブリック クラウドに移行する必要があります。

次に、企業文化の改善、インテリジェントな変更の実装、可観測性と監視という 3 つの側面から、エンタープライズ クラウド移行のベスト プラクティスと原則について説明します。これらのガイドラインをクラウド移行に適用すると、混乱や非効率を回避し、整理された状態を維持し、ツールを使用して移行を堅牢な方法で完了できるようになります。

ベスト プラクティスについて詳しく説明する前に、まずクラウド移行時によく使用されるさまざまなアプローチについて説明します。

クラウド移行の 5 つの R

クラウド環境の多様性、ビジネス ニーズの複雑さ、業界セグメントの違いにより、現時点では、すべてのニーズに適合するクラウド移行ガイダンス ソリューションは存在しません。ただし、従来の企業は、多くの場合、次の 5 つの R のいずれかを学んで実践することができます。

• 再ホスト: これは従来のリフトアンドシフト移行方法です。たとえば、アプリケーションは元々ローカル VM (仮想マシン) で実行されていましたが、クラウド サービス環境で実行されている VM に再デプロイする必要がある場合です。
• リファクタリング: 再ホストに似ていますが、リフト、調整、移行などの中間ステップが追加されます。
• 修正: これは、再ホストとリファクタリングを組み合わせたものです。通常、対象のクラウド環境の機能をより有効に活用するために、アプリケーションの大幅な変更が必要になります。
• 再構築: この方法は、修正方法よりもさらに一歩進んだものです。場合によっては、クラウド環境の機能をより有効に活用するために、アプリケーションを完全に再構築する必要があることもあります。
• 置換: このアプローチでは、組織はローカルで管理されていた機能の一部を削除し、サードパーティのソリューションに置き換えます。

ここで、これらの方法をクラウド サービスのシナリオに適用してみましょう。

• 再ホスト: ローカル仮想マシンで実行されているアプリケーションを、複数のクラウド サービスで実行されている仮想マシンに再デプロイできます。
• リファクタリング: 中間ステップを通じて各クラウド サービスの目標を調整できます。
• 修正: 各クラウド サービス ターゲットの機能を活用するために、アプリケーションに大幅な変更を加えます。
• 再構築: アプリケーションを完全に再構築することで、複数のクラウド サービス ターゲットの機能を活用します。
• 置換: 複数の潜在的なサードパーティ クラウド サービス オプションを使用して、ローカル アプリケーションの一部の機能を置き換えることができます。

前述の複数のクラウド サービス、特殊なユース ケース、さまざまな業界規制により、クラウド移行の複雑さが急速に増すことがわかります。そのため、企業はクラウド移行を合理化および簡素化するために、次の 3 つの重要な実践原則に従う必要があります。

1. 企業文化の改善

経営管理の経験がある人なら誰でも、最も困難でありながら最も価値のある実践の 1 つが企業文化の改善であることを知っています。一般的に言えば、クラウド移行を試みる前に、テクノロジー資産のどの部分の責任者が誰であるかを整理し、以下の側面を明確にすることから始めることができます。

（１）責任の決定

RACI マトリックス (下の図を参照) 手法を特定のコンポーネントまたはドメインに適用できます。移行中は、誰が責任を負うのか、誰が記録を提供するのか、誰が相談に応じるのか、そして発生するさまざまな変更について誰に通知するだけでよいのかが明確になります。クラウドサービスはサービスや製品の変革を加速させるため、企業やチームはそのような変化に適応する必要があり、変化に対応した役割が非常に重要になります。

（２）追跡指標

文化改善のもう 1 つの要素は、主要な指標を特定し、それを文書化することです。この動きによって、業務の非効率性などの問題が明らかになるのではないかと懸念する人もいるかもしれない。しかし、ショートボードの原則によれば、運用上の不均衡が一度生じると、全体のレベルを向上させることはできません。したがって、あらゆるレベルで指標を追跡する必要があります。例: アプリケーション チームの観点から、ネットワークとストレージのレイテンシに関するメトリックを追跡します。より高い管理レベルでは、サービス レベル目標 (SLO) のコンポーネントを簡潔かつ明確に定義および説明し、できるだけ多くのチームにそのような標準化された複合 SLO を認識させ、遵守させる必要があります。契約を履行するためにサービス レベル契約 (SLA) を使用しないのはなぜかと疑問に思うかもしれません。実際、SLA と比較すると、SLO は、現在のアプリケーションのパフォーマンスと信頼性が顧客とビジネス全体にどのような影響を与えるかを組織が理解するのに役立ちます。

（3）事業に関するあらゆる質問に効果的に回答する

プログラミングのアイデアをビジネスに拡張し、既存のビジネスの観測可能性と監視機能を向上させることができます。たとえば、チーム メンバーがビジネスへの影響に関する質問に答えるために PromQL クエリをコピーして貼り付ける必要がある場合、これを改善の機会と見なす必要があります。範囲が広く複雑になることもありますが、ほとんどの場合、データ ストアを柔軟な視覚化システムと組み合わせ、さまざまなレベルで選択的にクエリを開発して、ビジネス上の質問に迅速かつ正確に回答することで、オープン性と可観測性を実現できます。

2. 賢明な変更を実施する

変更管理は厳しくて堅苦しい印象を与えることが多く、変更管理委員会は「ノー」と言うだけの場合がほとんどです。そして、これは明らかに「インテリジェントな変化」の現れではありません。

スマート チェンジは、プロセス ゲーティングではなくテクニカル ゲーティングを使用するクラウド移行のアプローチです。言い換えれば、エンドツーエンドのテスト、継続的インテグレーション、分散トレースの証明などの自動化されたプロセスを通じて保護を実装する必要があります。技術的なゲートでカバーされていないもの（または実装に多くの作業を必要とするもの）は、移行リストの下位に配置する必要があります。

多くの場合、同様のプロセスに従う他のより複雑な部分への道を開くために、より小規模または単純なワークロード用のテクノロジー ゲートを作成する必要があります。同時に、十分なレベルの正確性と機能性が達成されるまで各部分を反復的に完了することで、クラウド移行作業の再現性を実現できます。

3. 可観測性と監視

前述したように、移行前にシステムとアプリケーションの観測可能性（まだ存在しない場合）を提供し、それに基づいて監視を行えるようにすることも、クラウド移行作業の成功を検証する上で重要です。たとえば、データベースへの接続を確立できるかどうかに基づいて、データベースが稼働中か停止中かを判断できます。使用率インジケーター、クエリ時間、アクティブな接続数などのパラメータ インジケーターを確認できる場合にのみ、データベースの可観測性を真に得ることができます。可観測性により、さらに次のような質問をすることができます。

監視データに基づいてアラートを受け取ることはできますか?

インフラストラクチャは監視に基づいて自己修復できますか?

監視データに基づいて、対応するシステムおよびアプリケーションにおける問題の根本原因を見つけるにはどのくらいの時間がかかりますか?

基本的に、監視可能性はクラウド移行時の意思決定の基礎となります。それがなければ、クラウドへの移行は暗いピッチで投球するようなものです。

したがって、移行チームによって行われたすべての変更と展開、およびシステムとアプリケーション環境への影響を追跡するための統合管理プラットフォームも必要です。したがって、クラウド移行中に問題が発生した場合、その観測性と監視を通じて適時に問題を発見し、必要に応じてロールバックまたは対処することができます。

最後に

実際、クラウド移行を簡単に実現する方法については業界内に優れた実践例が数多く存在し、各操作の詳細を解説した入門書も数多く存在します。ただし、上記の 3 つのプラクティスは、ソースからのクラウド移行を成功させる方法について、「誰が」、「何を」、「なぜ」行うかというアイデアを提供します。もちろん、「話すよりも行動するほうがよい」ということわざにあるように、成熟したクラウド サービス プロバイダーを慎重に選択し、Lightstep などの企業向けに構築されたクラウド ネイティブ SRE ツールを採用して、移行プロセス中に可観測性、監視、インシデント対応などの主要なプラットフォーム サービスを実装する必要があります。

翻訳者について

51CTO コミュニティの編集者である Julian Chen 氏は、IT プロジェクトの実装において 10 年以上の経験を持っています。社内外のリソースとリスクの管理に長けており、ネットワークと情報セキュリティの知識と経験の普及に注力しています。彼は、ブログ投稿、特別トピック、翻訳の形で最先端のテクノロジーと新しい知識を共有し続けています。彼はオンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。