®OTOKO®によるTelekom T Cloud Public
契約したTelekom Cloudサービスを本番稼働のアプリケーションにつなげるまでには、数多くの判断が必要です。ネットワーク構築、データ保管、権限設定、障害発生時の責任分担などです。T Cloud Public（旧Open Telekom Cloud）については、この統合作業をOTOKO®が担います。こうして、貴社のチームが構成を理解し、運用の担当も明確な環境が生まれます。
私たちが貴社のために担うこと
OTOKO®による計画、実装、合意した運用
イメージ画像（事業者の拠点を撮影したものではありません）OTOKO®へのご依頼内容
既存のOpen Telekom Cloud環境を拡張したい、オンプレミスのアプリケーションを移行したい、あるいは複数の拠点に共通のアクセス手段が必要である、といった状況が出発点になります。貴社のデータ経路と運用要件を起点に、必要なサービスと、貴社のチーム、TelekomまたはT-Systems、OTOKO®それぞれが担う作業を導き出します。
提供されたプラットフォームが基盤となります。これを土台として、OTOKO®のサービス範囲には、アーキテクチャ設計、構築、接続、そして合意したデータおよびアプリケーションの移行が含まれます。引き継ぎ前に、アクセス権、バックアップ、運用タスクを文書化します。継続的なサポートは、貴社が支援を必要とする対象のコンポーネントに限定することができます。
サービスの詳細サービス範囲
演算能力、ネットワーク、データ保管は互いに連動しています。以下のサービスは、これらを貴社の既存ITと結び付け、OTOKO®が担う統合および運用タスクを明確にします。
演算能力は、対象のアプリケーションに基づいて計画します。仕様や余力については共に決定し、仮想システムを構築して必要な環境を分離します。アクセス権、用途、責任の所在は、後の拡張時にそのまま参照できるように文書化します。
リージョン、システムの割り当て、プロビジョニング設定を文書化した、適切な規模のサーバーアーキテクチャ。
CPU、メモリ、オペレーティングシステム、負荷プロファイルに基づいて仮想サーバーを計画します。開発環境と本番環境には、それぞれ別のアクセス権と、すり合わせたプロビジョニングルールを設けます。利用可能なインスタンスタイプとリージョンごとのキャパシティは、実装前に貴社の要件に照らして確認します。
拠点、データベース、アプリケーションには、目的に応じた接続が必要です。それぞれの通信経路をもとに、適切なアクセス許可と名前解決を備えたネットワーク構成を設計します。設定後は、必要なサービスに到達できるか、また接続が途絶えた場合に運用へどのような影響があるかを共に確認します。
データフロー、許可された接続、結果を後から確認できるテストを含むネットワーク計画。
Virtual Private Cloud（VPC）、サブネット、セキュリティルールがネットワークの境界を形成します。VPNや適切な接続により、社内のシステムとTelekom Cloudを結びます。Elastic Load Balanceは、リクエストをアプリケーションインスタンスに分散できます。到達性、DNS、アクセス許可、接続障害発生時の挙動を確認します。
データ移行は、ファイルのコピー以上の作業です。保存先、データベースへのアクセス、バックアップの経路が、対象のアプリケーションに適している必要があります。転送の順序とテストは貴社のチームとすり合わせ、業務上の検収の前に完全性と利用可能性を確認できるようにします。
転送経路、役割分担、業務上の検収基準を含むデータ・ストレージ計画。
Object Storage Service（OBS）、ブロックストレージ、Relational Database Service（RDS）は、それぞれ異なる役割を担います。データ資産を適切なサービスに割り当て、転送、権限、バックアップを計画します。必要なストレージ容量とデータ通信量も試算に含めます。
コンテナアプリケーションには、イメージから稼働中のバージョンに至るまでの、明確に定めた手順が必要です。プラットフォームは、アクセス権、リソース、デプロイ手順とあわせて構築します。マネージドサービスを利用する場合でも、アプリケーションの設定、承認、データ復元といったタスクは、明確に割り当てられたままとなります。
リリースパス、アクセスモデル、運用への引き継ぎを備えた、関係者とすり合わせたコンテナプラットフォーム。
Cloud Container Engine（CCE）は、T Cloud Public上でコンテナ化されたアプリケーションを実行する選択肢の一つです。クラスター、ワーカー、ネットワーク、永続ストレージをアプリケーションチームとともに計画します。マネージドプラットフォームであっても、ロール、デプロイメントプロセス、更新には明確な役割分担が必要です。
誰がリソースを変更できるか、そして変更を後からどのように追跡できるかが課題となります。ロール、管理用アクセス、合意したログ記録により、貴社の要件を具体的な設定に落とし込みます。引き継ぎでは、実施した内容と、貴社側に残る組織上の判断事項を記録します。
文書化された権限設計と、実装済みの管理策および残タスクの一覧。
IAM、ログ記録、鍵管理は、貴社の社内規定と照らし合わせます。管理アクセス、ロール、権限は文書化します。設置場所の選択や事業者が取得した認証は、貴社の具体的なアプリケーションと設定の確認に代わるものではありません。必要な証跡はプロジェクトの中でまとめます。
日常の運用では、連絡が取れる担当者と、明確に割り当てられたタスクが重要です。サポートにあたっては、対象コンポーネント、保守、監視、変更経路をサービスカタログにまとめます。そこには、TelekomまたはT-Systemsが担当する場合と、OTOKO®または貴社のアプリケーションチームが担当する場合も明記します。
報告経路、サービス範囲、保守計画、復旧手順を含む運用モデル。
モニタリング、パッチ適用、バックアップ、変更対応について、貴社のチームとすり合わせます。TelekomまたはT-Systems、OTOKO®、アプリケーションチームの役割分担は、区別して記述します。サービス時間と対応目標は、選んだクラウドによってではなく、合意したサービスカタログに従って適用されます。
計画と実装の詳細
プラットフォームはリソースを提供します。そこから貴社にとって利用できる環境をどう作るかは、アプリケーション、データ経路、役割分担によって決まります。特に既存のOpen Telekom Cloud環境では、設定内容と運用体制を共に見直す価値があります。
出発点となるのは、貴社のアプリケーションが実際に何を必要としているかという点です。処理性能、データの保持方法、到達性、既存システムとの接続などです。希望するサーバーの一覧だけでは、どのコンポーネントが連携する必要があるか、負荷やデータ量がどのように推移するかは分かりません。こうした関係性を共に把握し、確定した要件と前提事項を切り分けます。これをもとに、適切なTelekom Cloudサービスの選定を準備します。既存のリソースも組み込むことで、正常に機能している構造が、業務上の理由もなく置き換えられることを防ぎます。
構築にあたっては、貴社のチームが構成を理解できるように、環境、権限、ネットワーク領域を割り当てます。テスト環境と本番アプリケーションには、それぞれ必要な境界を設けます。さらに、新しいリソースをどのように追加するか、誰が変更を承認するかも明確にします。ドキュメントには、初期状態だけでなく、想定される拡張方法も記載します。これは、複数の社内チームや外部のアプリケーションパートナーが、後で同じ環境で作業する場合に特に重要です。
Telekom Cloud上のアプリケーションは、引き続きオンプレミスのユーザー管理、データソース、他の拠点に依存する場合があります。そのため、こうした接続は計画の早い段階で考慮する必要があります。必要なデータ経路、名前解決、アクセスルールを共に確認します。また、接続が切断された場合にどの業務フローが機能し続ける必要があるかも検討します。これらの要件から、個々のリソースの到達性だけでなく、アプリケーションの通信全体を反映したテスト範囲を導き出します。
データ移行では、転送方法、データの時点、業務面での検証をすり合わせます。移行したデータでアプリケーションが正しく動作することを誰が確認するか、旧システムでの変更がいつまで許容されるか、切り替え前にどのバックアップを用意するか。これらの答えが、進め方と役割分担を決定します。技術的な準備が整った後は、合意したテストに立ち会い、未解決の点を記録します。こうしてデータ移行は、貴社のアプリケーションチームが業務面から成否を評価できる、計画的な切り替えになります。
提供されるクラウドサービスは、オペレーティングシステム、データ、アプリケーションに関するすべての業務を自動的に引き受けるわけではありません。そのためサポート開始前に、契約したプラットフォームのサービス範囲と、貴社の環境内で発生する作業とを区別します。これには例えば、設定変更、権限管理、更新後の業務面でのテスト、通知への対応が含まれます。TelekomまたはT-Systems、OTOKO®、貴社自身のチームの役割分担は、一般的な責任範囲を示すだけでなく、具体的な現状に基づいて記録します。
そこから導き出されるサポート範囲には、対象コンポーネント、サービス時間、報告経路を記載します。障害発生時には、誰が最初の評価を行い、他の関係者をどのように巻き込むかを明確にします。保守と復旧についても、担当者を明記します。一部の業務が貴社のIT部門に残る場合、貴社が担うその部分も明示的に文書化します。これによりキャパシティ計画が容易になり、後の拡張についても話し合いやすくなります。新しいアプリケーションを既存の範囲と照らし合わせて確認することで、気づかないうちに追加の運用業務が発生することを防げます。
私たちの協働の進め方
貴社が技術的な作業のすべてを自ら手配する必要はありません。私たちが作業内容と決定事項を記録し、貴社のチームの知見や承認が必要な場面には、その都度参加していただきます。
アプリケーションの要件と既存のTelekomサービスを突き合わせます。統合とサポートに関する未解決の項目は、作業範囲に反映します。
貴社の役割： 既存の資料をご提供いただき、プラットフォームおよびアプリケーションの担当者をお知らせください。
設定作業に続いて、アクセス、データ経路、対象となるアプリケーションのテストを行います。その結果に基づいて、引き継ぎの準備を進めます。
貴社の役割： 業務上の利用可能性を確認し、必要な変更内容を貴社のチームとすり合わせてください。
引き継ぎでは、TelekomまたはT-Systems、OTOKO®、貴社のチームそれぞれのタスクを区別します。報告経路と保守についても、それに沿って文書化します。
貴社の役割： 検収と、貴社のアプリケーションチームに残るタスクを確定してください。
プロジェクトのシナリオ例
共同で進めるプロジェクトの一例です。具体的な範囲は、貴社の現状によって決まります。
社内アプリケーションには新しいインフラが必要ですが、オンプレミスのサービスとの接続は維持する必要があります。
サービスと拠点の選定を計画し、接続をテストしたうえで、アプリケーションチームとともに移行の準備を進めます。
データ経路、責任分担、検収基準を明確にした、文書化された目標運用モデル。
貴社が得られるもの
サービスとリージョンの選定を文書化した、T Cloud目標像
移行、テスト、検収を含む実施計画
役割分担とコスト概要を文書化した運用
Telekom T Cloud Gold
貴社に適したTelekom Cloudサービスの選定と導入を支援します。データ保管場所、アクセスルール、運用範囲は、プロジェクトの中で明確に定めます。
旧Open Telekom Cloudは、現在T Cloud Publicという名称になっています。既存の環境も新しい計画も、接続、アイデンティティ、移行、運用に関する貴社の要件と合わせて検討します。
貴社のITとの接続を理解する関心から、具体的なご依頼へ
初回相談の時点では、これらの資料がすべて揃っている必要はありません。何がすでにあるか、アセスメントでどの情報を補うべきかを、共に明確にします。
サービス範囲、貴社チームの関与、必要なアクセス権、検収基準、引き渡しは、見積もりの中に記載します。事業者の利用料金、プロジェクトの作業内容、稼働中の運用は、それぞれ区別して分かりやすく示します。
アセスメントについて相談する着手前に
T Cloud Publicは、旧Open Telekom Cloudの現在の名称です。プロジェクトの中で、貴社の要件を満たすTelekomのサービス、リージョン、運用内容を明確に定めます。
企業向けTelekom Cloud。OTOKO®は、T Cloud Public（旧Open Telekom Cloud）について、コンサルティングとアーキテクチャから移行、Kubernetes、そして合意したマネージド運用まで支援します。
はい。貴社のインターフェース、アイデンティティ、ネットワーク、可用性やデータ保管場所に関する要件をもとに、ハイブリッドアーキテクチャを計画します。
Open Telekom Cloudは、T Cloud Publicに名称を変更しました。「Telekom Cloud」という呼び方は、口語的にTelekomの複数のクラウドサービスを指すことがあります。そのため、ご提案の中でT Cloud Publicか他のサービスかを明記します。
具体的な事業者と契約範囲は、貴社のクラウド契約によって定まります。OTOKO®は、合意したコンサルティング、統合、運用の業務を補完します。責任分担マトリクスにより、プラットフォーム、オペレーティングシステム、データ、アプリケーションの境界を明確にします。
プラットフォーム名だけでこれが保証されるわけではありません。リージョン、サービス、バックアップ目標、接続先システムは、貴社の要件に基づいて選定し、文書化します。データ処理全体は、それぞれの案件ごとに検討する必要があります。
はい。まずプロジェクト、アクセス、ネットワーク、運用手順のアセスメントから始めます。名称変更だけを理由に一律で作り直す必要はなく、必要な変更は貴社の実際の環境から導き出します。
OTOKO®によるTelekom T Cloud Public
新規のアプリケーションであっても、既存のOpen Telekom Cloudランドスケープであっても構いません。システム、拠点、希望するサポート内容の概要さえあれば、まずは十分です。そこから次の技術的なステップを検討し、責任分担を定めます。
Telekom T Cloud Publicに関する初回相談
