®OTOKO®によるハイブリッド・マルチクラウド
生産現場に近いシステムはオンプレミスに残り、新しいアプリケーションはクラウドで稼働し、一部のサービスは別の事業者から利用しています。こうした環境には、拠点の境界を越えたアーキテクチャが必要です。OTOKO®は、データセンター、Azure、Telekom T Cloud、その他の環境を接続すると同時に、データ経路、アクセス、障害の責任者を明確にします。
私たちが貴社のために担うこと
OTOKO®による計画、実装、合意した運用
イメージ画像（事業者の拠点を撮影したものではありません）OTOKO®へのご依頼内容
プラットフォームを1つ追加しただけでは、アプリケーション間の依存関係は自動的には解消されません。データを分散させると、応答時間が長くなったり、通信量が増えたり、新たな障害要因が生じたりすることがあります。そのため私たちは、まずどのコンポーネントを一体として保つべきか、そして分散が業務上どのような目的を果たすのかを確認します。
この統合には、合意したネットワークとアクセスの構築、および関係するデータ経路のテストが含まれます。これに加えて、事業者の垣根を越えた運用とエスカレーションの調整、残る依存関係の文書化を行います。将来の切り替えについても、データのエクスポートと工数の観点から評価します。
サービスの詳細サービス範囲
まず、アプリケーションの適切な配置を評価します。続いて、接続と共通の運用手順を整えます。現在の構成をひとまず維持する場合でも、依存関係と切り替えにかかる工数は検討の対象に含めます。
データフローと応答時間は、アプリケーションをどこで稼働させるべきかの判断材料になります。関連するコンポーネントについては、依存関係を確認します。その上で目標像では、どの部分をオンプレミスに残し、どの部分を他の環境に分散させるのが適切か、その根拠を示します。
文書化されたデータフローとアーキテクチャの境界を含む、ワークロードの割り当て。
レイテンシー、データ量、依存関係が、アプリケーションをどこで実行するのが適切かを左右します。どのコンポーネントを一体として保つべきか、どのコンポーネントが定義済みのインターフェースを通じて通信できるかを確認します。データの所在地は、処理経路全体を通じて検討します。
接続は、状況が変化しても機能する必要があります。そのため、想定するネットワーク経路とアクセスルールを構築した後、中断が発生した場合の影響をテストします。これにより、どのアプリケーションが影響を受け、運用面でどのような対応が必要になるかが明らかになります。
通常運用時と障害時のテストケースを含む接続設計。
接続には、すり合わせたルーティング、名前解決、アクセスルールを設けます。ExpressRouteはAzureの選択肢の一つであり、Telekomや他のクラウド接続は、具体的なサービス内容に応じて計画します。障害と利用可能な帯域幅も評価の対象です。
複数の事業者が関わる場合、障害が責任分担のはざまに埋もれてはなりません。報告経路、アクセス管理の責任、変更調整は、共に取り決めます。運用ドキュメントには、誰がインシデントを引き受け、他にどの関係者を関与させるべきかを明記します。
責任分担マトリクスと、すり合わせたアクセス・エスカレーション手順。
ユーザーとシステムがどのようにサービスにアクセスし、誰が変更を承認するかを明確にします。モニタリングとエスカレーションは、複数のプラットフォームの境界をまたぐ必要があります。共通の運用設計により、社内IT、クラウド事業者、OTOKO®のそれぞれが何に責任を負うかが明確になります。
事業者を切り替えられるかどうかは、データ形式、エクスポート方法、利用しているサービスに左右されます。こうした依存関係を洗い出し、必要な工数の観点から評価します。さらに、継続的な通信量と追加の運用作業も検討し、分散構成の経済性を説明できる状態に保ちます。
残る依存関係と工数の前提を含む、文書化された撤退方針。
コンテナとInfrastructure as Codeは再現性の確保に役立ちますが、それだけでサービスが自動的に置き換え可能になるわけではありません。プラットフォーム固有の依存関係、データのエクスポート、切り替えの手間を把握します。継続的なデータ転送と重複する運用業務も、コスト評価に含めます。
計画と実装の詳細
ハイブリッドクラウドおよびマルチクラウドのアーキテクチャは、既存のシステムと新たな可能性を結び付けられます。ただし、技術面と運用面に追加のインターフェースをもたらします。そこで、まず、環境を分散させる目的を確認し、それに沿って各環境の連携方法を設計します。
システムを適切に配置するには、そのデータ経路を把握しておく必要があります。オンプレミスで稼働するアプリケーションは、データベース、機器接続、ユーザー管理と密接に結び付いている場合があります。一部だけを移すと、応答時間や接続への依存度が重要になることがあります。そこで、どのコンポーネントを一緒に置くべきか、どれを実際に切り離して稼働できるかを貴社とともに検討します。複数のクラウド事業者を利用したいという意向は、それ自体を目的とするのではなく、こうした要件と照らして評価します。
目標像では、業務上のメリットと追加の工数の両方を考慮します。異なる環境ではそれぞれ独自のアクセス手順、ツール、スキルが必要になる場合があります。継続的なデータ通信や共通インターフェースの保守も検討の対象です。判断内容は、あるアプリケーションを特定の場所にとどめる理由、あるいはそこへ移す理由として文書化します。こうして、後の変更に対しても検証可能であり、配置がアプリケーションの要件から説明できるアーキテクチャが出来上がります。
ネットワーク接続が確立できたというだけでは、その接続を介してアプリケーションが完全に機能することの証明にはなりません。名前解決、ユーザー権限、データアクセス、外部インターフェースには、それぞれ追加の前提条件がある場合があります。そのため実装の際には、必要な通信経路を貴社とともに洗い出し、構築します。その後、技術担当者と業務担当者が関連する処理を確認します。これにより、環境が単に到達可能であるだけでなく、新しい条件のもとで想定した処理を実際に果たせるかを確かめられます。
さらに、通信が途絶えた場合に何が起きるかも評価します。具体的には、どのコンポーネントが利用可能なままか、どの処理が待機状態になるか、どのデータを後で突き合わせる必要があるか、という点です。これらの答えによって、運用にどのような手順が必要かが決まります。テストと文書化により、選定したアーキテクチャの限界が明らかになります。望ましい挙動が得られない場合は、調整、追加対策、あるいは残る制約の受け入れについて、意図的な判断を下す必要があります。この判断は、統合の検収に含まれます。
複数の環境にまたがる障害が発生すると、どの部分が原因かが当初は分からないことがよくあります。報告経路が定まっていないと、複数の関係者がそれぞれ別の担当範囲を指し示してしまいかねません。そこで、誰がインシデントを受け付け、どのような情報が必要で、他の関係者をどのように巻き込むかを貴社とともに定めます。あわせて、変更時のすり合わせ方法も定め、ある環境への変更が、他のアプリケーションや拠点に気付かれないまま影響を及ぼすことのないようにします。
将来の事業者の乗り換えは、データのエクスポート、利用しているサービス、設定、アプリケーションに必要な調整といった具体的な依存関係に基づいて検討します。複数の事業者を利用しているからといって、アプリケーションをそのまま事業者間で移動できるとは限りません。こうした限界を文書化し、想定される工数を整理します。これにより貴社のチームは、将来の意思決定のための明確な根拠を得るとともに、乗り換えや環境の統合にどのような準備が必要かを見積もれるようになります。
私たちの協働の進め方
貴社が技術的な作業のすべてを自ら手配する必要はありません。私たちが作業内容と決定事項を記録し、貴社のチームの知見や承認が必要な場面には、その都度参加していただきます。
依存関係と応答時間の要件によって、適切な配置が決まります。そこから、必要な接続と運用インターフェースを導き出します。
貴社の役割： 重要な業務プロセスをご説明いただき、関係する各環境の担当者を明確にしてください。
接続とアクセス権を構築し、アプリケーションの通信経路全体を通して確認します。中断が発生した場合の挙動もあわせて検討します。
貴社の役割： テストと影響評価には、各システムのチームにもご参加いただくようお願いします。
報告経路と変更調整の手順を、関係者全員にわたって文書化します。残る依存関係は、今後の判断に備えて可視化しておきます。
貴社の役割： 関係する各環境について、担当者とエスカレーション経路をご確認ください。
プロジェクトのシナリオ例
共同で進めるプロジェクトの一例です。具体的な範囲は、貴社の現状によって決まります。
拠点に近いシステムはそのまま維持したい一方で、公開ポータルは柔軟に発展させていく必要があります。
データフローの範囲を明確にし、接続、ID、接続障害時の挙動を計画します。
文書化されたハイブリッドアーキテクチャが、分かりやすいセキュリティ境界と運用境界のもとで、両方の環境をつなぎます。
貴社が得られるもの
ワークロードごとの根拠を示す配置マトリクス
すべての環境にまたがるネットワーク・IDアーキテクチャ
アプリケーションごとの切り替え経路を含む出口戦略
関心から、具体的なご依頼へ
初回相談の時点では、これらの資料がすべて揃っている必要はありません。何がすでにあるか、アセスメントでどの情報を補うべきかを、共に明確にします。
サービス範囲、貴社チームの関与、必要なアクセス権、検収基準、引き渡しは、見積もりの中に記載します。事業者の利用料金、プロジェクトの作業内容、稼働中の運用は、それぞれ区別して分かりやすく示します。
アセスメントについて相談する着手前に
ワークロードごとの根拠を示す配置マトリクス. すべての環境にまたがるネットワーク・IDアーキテクチャ. アプリケーションごとの切り替え経路を含む出口戦略。範囲と検収基準は最初に合意します。
はい。既存のアプリケーション、インターフェース、運用プロセスを確認し、必要な変更を貴社と一緒に切り分けます。必ずしも全面的な再構築が必要になるわけではありません。
棚卸しの後、作業パッケージ、役割分担、検収基準、引き渡しをすり合わせます。そこから具体的なプロジェクト範囲の見積もりを作成します。
いいえ。共通のアイデンティティ、ネットワーク、データベースは、依然として単一障害点になり得ます。事業者を追加しても、それに見合った設計で検証済みのアプリケーションアーキテクチャがなければ、可用性は向上しません。
いいえ。データベース、ストレージ、ネットワーク、運用プロセスは、多くの場合プラットフォーム固有のまま残ります。ワークロード全体について可搬性を評価します。
OTOKO®によるハイブリッド・マルチクラウド
現在、環境の境界を越えて連携しているアプリケーションについてお聞かせください。データ経路、応答時間、責任分担を共に検討し、最初にどの統合が必要かを定めます。
ハイブリッド・マルチクラウドに関する初回相談
