®OTOKO®によるOVHcloud
仮想リソース、専用システム、あるいはその組み合わせなど、OVHcloudは貴社のインフラに向けたさまざまな出発点を提供します。重要なのは、アプリケーション、ネットワーク、データ保管がどのように連携するかです。OTOKO®はこのアーキテクチャを設計し、選定した環境を構築したうえで、後の運用タスクを見据えながら移行と引き継ぎに伴走します。
私たちが貴社のために担うこと
OTOKO®による計画、実装、合意した運用
イメージ画像（事業者の拠点を撮影したものではありません）OTOKO®へのご依頼内容
ホスティング契約を統合したり、アプリケーションを新しいシステムに分散させたりする際には、データ経路と責任分担が変化します。そのため、キャパシティやサーバー価格だけでなく、アクセス、バックアップ、保守にかかる工数もあわせて検討します。これにより、貴社の具体的な現状に即した、根拠のある構成が生まれます。
範囲を明確にしたインフラ構築も、その後のサポートを伴う移行も、どちらも可能です。含まれる内容は、合意した設定、接続テスト、引き継ぎのドキュメント作成です。OS、アプリケーション、プラットフォームに関するタスクは個別に割り当て、貴社のチームが自ら対応すべき残りの工数を把握できるようにします。
サービスの詳細サービス範囲
リソースの選定と統合は、あわせて計画します。作業項目には、基盤構築のほか、コンテナアプリケーションやデータ移行も含まれます。具体的な範囲は、貴社のアプリケーション構成に応じて決まります。
リソースの必要量は、貴社のアプリケーションの負荷、データ量、依存関係から導き出されます。これに基づいて、適切なクラウドリソースまたは専用システムを選定し、構築します。キャパシティの前提や余力は記録し、後の拡張を根拠の明確な判断に基づいて行えるようにします。
アプリケーションへの割り当てと根拠あるインフラ選定を含むリソース計画。
コンピューティング性能、ストレージの挙動、ライセンス要件がリソース選定を左右します。適切なインスタンスと専用システムを比較し、選定したリージョンを確認します。キャパシティの前提、予備容量、依存関係は目標像に記録します。
個々に用意されたサーバーだけでは、まだ機能する環境にはなりません。プライベートおよびパブリックの接続、名前解決、アクセスルールは、想定される通信内容に基づいて構築します。その後、テストによりアプリケーションのデータ経路全体を確認します。
アクセス許可、ルーティング、検証済みのデータ経路を含む、文書化されたネットワーク構成。
必要なインフラコンポーネント間のプライベートな通信経路を計画します。vRackが適しているか、サービス固有のプライベートネットワーク接続が適しているかは、選定したサービスによって決まります。公開エンドポイント、ファイアウォールルール、DNSも同じアーキテクチャ判断の一部です。
コンテナアプリケーション向けに、合意したKubernetes環境を構築し、デプロイの流れを検証します。この引き継ぎには、ロール、更新手順、開発と運用の間のタスク分担が含まれます。これにより、貴社のチームはプラットフォームとその利用方法を把握できるようになります。
デプロイメントの流れと、更新に関する合意済みの責任を備えた、利用可能なプラットフォーム構成。
OVHcloud Managed Kubernetes Serviceは、コンテナ化されたアプリケーションの基盤となり得ます。ワーカー、ストレージ、レジストリ、アクセス権は、リリースプロセスに合わせて計画します。アプリケーション、設定、運用手順に対する責任は、明示的に取り決める必要があります。
移行の際は、データの状態、切り替えのタイミング、バックアップを互いに整合させる必要があります。転送とテストは共に計画し、新しい環境をどのように引き継ぐかを定めます。その際、ドキュメントではプラットフォーム、OS、アプリケーションそれぞれのタスクを明確に区別します。
検収と復旧要件を含むデータ移行・運用設計。
アクセス挙動に基づいて、オブジェクトストレージや他のデータコンポーネントを確認します。データ転送、バックアップ、復旧は別々に計画します。継続的な運用業務と事業者の対応範囲は、システムを引き継ぐ前に明確にします。
計画と実装の詳細
インフラに関する意思決定は、処理性能の選定だけにとどまりません。クラウドリソースと専用システムは、どのように統合し、拡張し、運用していくかという点でも異なります。貴社のチームにとって影響が把握できる構成を、共に作り上げます。
ホスティング環境を統合する際には、非常に多様なアプリケーションに直面することが多くあります。一部は主に安定した処理性能を必要とし、他はデータ保持、ネットワーク、拡張性に特別な要件を持っています。共通のサーバーサイズでは、こうした違いに必ずしも対応できるわけではありません。そのため計画は、アプリケーション、想定される負荷、依存関係の対応付けから始めます。既存の契約や今後の変更も考慮に入れることで、目標とする構成が、現状だけでなく、見通せる次のステップも反映したものになります。
これに基づいて、適切なクラウドリソースまたは専用システムを選定し、全体構成における役割を記載します。その際、役割分担と、後で発生する自社の作業負担も明確にしておきます。例えばあるアプリケーションが追加の保守や特別なバックアップ手順を必要とする場合、それも構成の意思決定に含まれます。合意した構成は、その後設定し、文書化します。これにより貴社のチームは、根拠のあるリソース配分を得られ、個々の調達をその都度単独で判断するのではなく、後の拡張についても同じ要件に照らして評価できるようになります。
アプリケーションは、外部から到達可能なサービス、内部データベース、管理者用アクセスで構成されることがあります。これらの領域は、不要な通信経路を開くことなく、目的に応じて接続する必要があります。そのため、プライベートおよびパブリックな接続、名前解決、必要なアクセスルールを共に検討します。他の拠点にあるシステムが関わる場合は、そのデータ経路も組み込みます。その後のテストは、アプリケーションの通信全体と、実際にどのユーザーやシステムが連携する必要があるかを基準に行います。
コンテナアプリケーションの場合は、これに加えてデプロイの経路が関わります。新しいバージョンには、定められたアクセス、検証、承認が必要であり、プラットフォームの変更は関係するチームとすり合わせる必要があります。合意した範囲の中で、こうした基盤を整備し、具体的なアプリケーションで検証します。したがって引き継ぎには、プラットフォームの設定だけでなく、想定される変更対応の進め方も含まれます。開発チームと運用チームは、自分たちがどの業務を担当し、どの部分で引き続きすり合わせが必要かを把握できます。
移行の際には、データ移行、アクセス権、運用準備状況が同じタイミングで揃っている必要があります。そのため転送の前に、最新のデータをどのように提供し、検証し、その後利用するかを明確にします。必要な中断や業務面でのテストは、貴社の担当者とすり合わせます。切り戻しについても、切り替えの前に検討します。目指すのは、関係者全員が、承認の前にどのような結果が揃っている必要があるか、そして誰がそれを判断するかを理解している移行です。
検収の後、プラットフォーム、オペレーティングシステム、アプリケーションに関する業務を、それぞれ分けて文書化します。これにはバックアップ、復旧、保守、通知への対応が含まれます。サポート契約は、こうした業務を的確に補うことができますが、契約した事業者の提供範囲や貴社の社内業務との必要な切り分けに代わるものではありません。未解決の項目は、担当者と共に引き継ぎます。これにより、プロジェクト終了後も、何が構築されたか、どの手順が利用できるか、次にどの作業を計画すべきかが明確に分かります。
私たちの協働の進め方
貴社が技術的な作業のすべてを自ら手配する必要はありません。私たちが作業内容と決定事項を記録し、貴社のチームの知見や承認が必要な場面には、その都度参加していただきます。
アプリケーションの負荷、データ量、既存システムが、リソース選定の基盤となります。ネットワークおよび運用要件もあわせて評価します。
貴社の役割： 利用状況、想定される成長、既存のホスティングに関する依存関係をご説明ください。
移行先の環境を構築し、対象のアプリケーションに基づいてテストします。データ移行には、合意した確認ポイントと切り替えポイントを設定します。
貴社の役割： 業務テストと、必要なメンテナンスウィンドウの承認を手配してください。
引き継ぎでは、プラットフォーム、OS、アプリケーションをそれぞれ個別に扱います。バックアップと変更の手順には、それぞれ担当者を定めます。
貴社の役割： どのタスクを社内で継続し、どのタスクをサポートに引き渡すかを確定してください。
プロジェクトのシナリオ例
共同で進めるプロジェクトの一例です。具体的な範囲は、貴社の現状によって決まります。
アプリケーションは、保守体制の異なるシステム上に分散しており、ドキュメントと復旧手順は統一されていません。
共通の目標像を策定し、事前に取り決めたグループ単位でアプリケーションを移行します。
文書化された運用タスクと、今後の自動化のための基盤を備えた、整理されたインフラストラクチャ。
貴社が得られるもの
アプリケーションとネットワークの割り当てを含むOVHcloud目標アーキテクチャ
移行、テスト、検収を含む実施計画
役割分担とコスト概要を文書化した運用
関心から、具体的なご依頼へ
初回相談の時点では、これらの資料がすべて揃っている必要はありません。何がすでにあるか、アセスメントでどの情報を補うべきかを、共に明確にします。
サービス範囲、貴社チームの関与、必要なアクセス権、検収基準、引き渡しは、見積もりの中に記載します。事業者の利用料金、プロジェクトの作業内容、稼働中の運用は、それぞれ区別して分かりやすく示します。
アセスメントについて相談する着手前に
貴社のアプリケーション、データ要件、インターフェース、運用目標を、必要なサービス内容と照らし合わせます。具体的な選定内容は、アーキテクチャ設計書に記載します。
貴社のアプリケーションに適したクラウドインフラを構築する。OVHcloud環境を計画し、移行を支援し、既存システムに統合します。
はい。貴社のインターフェース、アイデンティティ、ネットワーク、可用性やデータ保管場所に関する要件をもとに、ハイブリッドアーキテクチャを計画します。
いいえ。契約したプラットフォームの範囲と、貴社のアプリケーションの運用支援は別のサービスです。ワーカー、設定、デプロイメント、データ、インシデント対応については、個別に取り決めます。
必要なサービスと接続に基づいて組み合わせを検討します。ネットワークの選択肢、リージョン、データ通信量は、選定したアーキテクチャに合っている必要があります。
OTOKO®によるOVHcloud
アプリケーションと既存のホスティング構成の一覧が、最初のお話し合いの土台となります。これをもとに、移行先の環境、データ移行、運用タスクの分担についてご相談します。
OVHcloudに関する初回相談
