Managed Service Column ＜システム運用コラム＞基幹システムのクラウド移行プロジェクトでよくある課題とは？実例を元に当社の解決アプローチをご紹介

はじめに

当社では構築や運用だけではなく、お客様の推進するプロジェクトに参加して技術支援を行う、といったこともやっています。特に多いのが以下のようなご相談です。

今回は、過去の実際にあった事例として、ハイブリッドクラウドへの移行を計画されていたお客様が抱えていた課題と当社の取ったアプローチを紹介します。

1. お客様の背景と課題

今回紹介するお客様のご相談内容は「オンプレミスで稼働している基幹システムをクラウドに移行したい」というものでした。

対象の基幹システムは複数のサブシステムから構成される巨大なものであり、移行にあたってはサブシステムごとに担当のアプリベンダがついています。移行先は AWS だったり、Azure だったりと様々であり、それらを本社や各拠点も含めて閉域網（= 専用線）で繋ぐというものでした。

重要な要件として「サブシステム間の通信は全て閉域網で行う」というものがありました。これはもともとが 1 つの基幹システムだったことから、セキュリティレベルを落とさないように要請されたものです。

しかし、具体的にどのように実現・実装するのか、については各アプリベンダとの合意が取れておらず、不透明な状態になっていました。

当社が最も懸念していたのは、一部のアプリが PaaS や SaaS といったマネージドサービスの利用を前提としていたことです。クラウドプロバイダやサービスにも依りますが、マネージドサービスは原則としてインターネット経由での通信を前提としており、閉域網での通信では一工夫必要なことが多いからです。

当社はもともと、システム全体の設計を行うために本プロジェクトに参加したのですが、「アプリ側でどう要件を満たす実装をするのか」が明らかにならないとインフラ側の構成も定まらないため、この問題を解決することを最優先事項としました。

2. アプローチ

この問題を解決するため、次のようなアプローチを取りました。

1. 通信要件の整理 :
   各アプリベンダとミーティングを行い、サブシステム間でデータのやりとりを行うのは何のクラウドサービスで、どのような通信をさせたいのかをヒアリングする。
2. 技術検証 :
   リストアップされたクラウドサービスについて、プライベートアクセスが可能かを技術検証する。
3. ベンダとの調整 :
   技術検証にて明らかになった実装方法を各アプリベンダに伝え、アプリ側で必要な対応を明らかにする。

「マネージドサービスを利用してプライベートアクセスできるのか？」という懸念は、当社のこれまでの経験から来る推測です。この推測に関して技術的に裏を取っていくことで客観的な事実としていく、というアプローチになります。技術支援として参加しているプロジェクトではよく行っている手法です。

アプローチ 1 : 通信要件の整理

まず、各アプリベンダにヒアリングを行い、どのようなクラウドサービスを使って、どのような通信をさせるのかを洗い出すことにしました。つまり、アプリ側からの通信要件を整理するということです。具体的には、以下のような情報を各アプリベンダにヒアリングすることにしました。

• アプリケーションが他システムとデータをやりとりする際のインターフェイスは、何のクラウドサービスを利用するのか。
• 対向先のサブシステムはどこで、プロトコルは何か。

インターフェイスとなるクラウドサービスについては、送信側なのか受信側なのかもヒアリングする必要があります。受信側は基本的にマネージドサービスの仕様に左右されます。そもそもサービスの仕様として対応していない可能性もありますし、対応していたとしてもインフラ構成の変更が必要な場合があります。また、送信側であれば、AWS マネージドサービスの仕様だけではなく、クライアントからのアクセス方法に変更があるか、変更があるならクライアントアプリはそれに対応しているか、といった観点も必要となります。

まず、各アプリベンダにシステム構成図を用意してもらい、ミーティングの場で説明してもらいました。システム構成図を見ながら、先述のヒアリング事項を確認し、関係者の認識を合わせていきます。情報を整理するには基幹システム全体の仕様を理解している必要があるため、ドキュメント作成はお客様、及び、一緒にプロジェクトを推進していたコンサル会社に行っていただきました。結果として、Lambda、S3、API Gateway といったマネージドサービスが他サブシステムとの通信インターフェイスになることがわかりました。

• Lambda : 受信、送信
• S3 : 受信
• API Gateway : 受信

その他のインターフェイスは IaaS でしたので、プライベートアクセスするための特別な考慮は不要でした。

アプローチ 2 : 技術検証

次に、Lambda、S3、API Gateway のそれぞれについてプライベートアクセスさせるための実装方法を検証しました。

Lambda は通常、ネットワーク上に存在しないマネージドサービスなのですが、ネットワーク （VPC） 上に作成する構成も取ることができます。ネットワーク上に作成してしまえば、IaaS と同じように扱うことができるため、受送信ともに懸念事項はありませんでした。

S3 については Lambda と違ってネットワーク上に作成することはできません。しかし、踏み台のようなネットワークを作成し、そこにインターフェイスとなる Private Link を用意することで、プライベートアクセスが可能なことがわかりました。クライアント用 DNS の用意など、名前解決するための特別な仕組みは不要です。しかし、プライベートアクセスを行う場合は、通常はバケット名だけを指定すればよいところが、エンドポイント名も追加で指定しなければならないことが明らかになりました。

API Gateway に関しても S3 と同様に踏み台ネットワーク上に Private Link を用意することでプライベートアクセスが可能になります。ただし、「プライベート DNS 」という設定値を有効にするかどうかでアクセス方法が変わることがわかりました。技術的な詳細は省きますが「クライアント側でどのように名前解決するか」という設定です。これに関しては実際に検証環境上にてシステムを構築し、有効・無効による振る舞いの違いを検証しました。アクセス元が AWS 以外になるケースもあったため、クライアント用 DNS に何を指定するかも考慮し、アクセスパターンを洗い出しました。

結論として、各サービスはインターネット経由での通信を基本としているものの、構成を少し変えればプライベートアクセスも可能なことがわかりました。しかし、S3 と API Gateway についてはアクセスするためのコマンドが変わってしまうことがわかりました。これは、接続する側のアプリに影響を及ぼします。

アプローチ 3 : ベンダとの調整

最後に、技術検証にて明らかになった結果を各アプリベンダに伝えました。技術的な内容になるので、当社がお客様の代わりに AWS マネージドサービスの仕様や、懸念されるアプリへの影響などを説明します。

結論として、S3 に接続するクライアントアプリへの影響が大きいことが明らかになりました。このアプリはパッケージ化されたものであり、接続コマンドを簡単に変えることができないからです。改修するには時間も費用もかかってしまいます。

3. 要件の見直しへ

そもそもの要件である「サブシステム間の通信は全て閉域網（= 専用線経由）で行いたい」の本来の目的 （要求）は「セキュリティレベルを下げたくない」から来ています。実現が難しいことが明らかになった段階で改めて、お客様に「全ての通信を閉域網内にしないと本当にセキュリティレベルを保てないのか」といったところに立ち戻っていただきました。

要件について見直していただいた結果、マネージドサービス間で発生する通信には個人情報などは含まれておらず、外部公開しても問題ないシステムであることがわかりました。この再検討には、「アプローチ」にてまとめていた通信要件の資料も役に立ちました。

結果として「通信の内容に応じて、サブシステムごとの公開・非公開を定義する」と要件を再定義して、この問題は解決しました。今回のお客様は技術的にも詳しい方たちでしたので、技術的な裏付けを丁寧に行っていくことで、すぐに方針転換の判断をしていただくことができました。

要件定義はシステム構築にあたって最も重要なフェーズですが、当社にご相談いただく前に既にお客様側で済まされていることも多いです。しかし、当社では必ず、以下の点についてチェックしています。

もし、これらを満たしていない場合は、既に決まっている要件であっても、遠慮なく見直しを指摘させていただきます。 既に決まってしまったことを覆すのは非常に難しいことですが、技術的な裏付けを行って判断材料を集めることで、お客様側での再検討がしやすくなるものと考えています。

まとめ

当社の専門分野はインフラレイヤではありますが、今回の事例のように、インフラの観点からアプリの要件・設計について指摘したり、システム全体を俯瞰してのアドバイスを行ったりすることが可能です。

また、プロジェクトが巨大になり、関係する会社も増えると、ベンダコントロールが重要になってきます。 昨今の IT 業界では技術やサービスが多様化しており、各ベンダと会話にするにも幅広い専門知識が必要になってきています。当社は1ベンダとしてプロジェクトに参加するのではなく、お客様とタッグを組んで、お客様に代わって調整事を行う、といったことを得意としています。

本コラムでのアプローチはあくまで1つの例ではありますが、当社の関わり方のイメージを掴んでいただけたら幸いです。

Tag： 基幹システム刷新

• 

  サイバー攻撃の目的とは？最新のサイバー攻撃の動向とトレンドについて解説

• 

  オンプレミスからクラウドへ移行するには？メリット・デメリットや移行の手順を解説！