(テックサービス)の関係がうまくいかない場合

チュートリアル
AWS

人生の中で愛する人に出会った日々を思い返してみてください。その感情は相互的でした。世界はより良い場所のように思え、あなたは大切な人と共に刺激的な旅をしていました。あなたたちは共に「全力投球」をしながら、共に過ごす未来の計画を立てていました。

人生は素晴らしかった…それがそうでなくなるまでは。

物事が計画通りに進まないとき、あなたは関係を解消するという困難な作業に取り組まなければなりません。お互いに、そして他の人々ともコミュニケーションをとり、共有した購入を整理し、前に進まなければなりません。はぁ。

信じられないかもしれませんが、私たちのテクノロジーとの関係もそれほど変わりません。

サービスとの別れ

あなたがサービスを採用することを決めた時期がありました。それはSaaSかPaaS、あるいはもっと一般的なものでした。その当時、あなたはそのサービスをもう使わなくなる時期を考慮しながら決定しましたか？おそらく、そうではなかったでしょう。未来の素晴らしい可能性についてだけを考えていました。

しかし、そのサービスを利用することがもはやあなたにとって最善の利益でなくなったとき、何が起こるのでしょうか？今、あなたは挑戦に直面しています。それはサービスの放棄と呼ばれています。サービスは合理的な努力で停止できますが、基礎データを取得することは問題がある場合があります。これはしばしば、そのサービスの種類やそのサービスプロバイダーが所有するデータの量に依存します。

時には、理想的な解消はこう見えます：サービスの支払いを停止しますが、ある期間データソースへのアクセスを保持します。これは本当に可能でしょうか？はい、可能です！

VPCピアリングの力

主要なクラウドプロバイダーは、リソース間の接続を確立するためのデファクトアプローチとして、仮想プライベートクラウド（VPC）ネットワークを採用しています。たとえば、AWSのEC2インスタンスは、VPCおよびVPCエンドポイントサービスを使用してデータソースにアクセスできます。これは、ポイントツーポイントの接続と考えてください。

VPCを使用すると、同じクラウドプロバイダー内の他のリソースへのアクセス権限を付与できますが、外部サービスへのアクセス権限も付与できます。たとえば、最近放棄されたサービスがありますが、元のデータソースはそのまま残っています。こういった場合はどうなるかを考えてみましょう：

この概念はVPCピアリングと呼ばれ、別のネットワークからプライベート接続を確立することを可能にします。

サービス移行の例

具体的な例を考えてみましょう。組織内で、クラウドでの運用方法を合理化するためのビジネス上の決定がなされました。AWSの一部のサービスを引き続き活用しつつ、組織は、AWSで実行されているサードパーティのクラウドベースのサービスを終了することで、アプリケーションの構築、デプロイ、および管理方法を最適化したいと考えていました。彼らは数値を検討し、内部のソフトウェアエンジニアが、サードパーティプロバイダーに支払っていたコストの一部でHerokuで新しいオートスケーリングサービスを立ち上げてサポートできると結論付けました。

しかし、サービスプロバイダーとの長期契約のため、データソースの移行は今すぐには選択肢ではありません。サービスは必要ないし、データを移動できないが、それでもデータへのアクセスを望んでいる。幸いにも、プロバイダーはデータのホスティングを続けてアクセスを提供する新しい契約に同意しました — VPCピアリングを介してです。

新しい取り決めは次のようになります：

HerokuとのVPCピアリング

新しいサービス（Herokuアプリ）がAWS内の元のデータソースにアクセスするためには、まずプライベートスペース内でアプリを実行する必要があります。詳細については、安全なクラウド導入とHerokuプライベートスペースの発見について読むことができます。

次に、以下の簡単なネットワーク要件を満たす必要があります：

  • VPCは、ネットワーク構成で互換性のあるIPv4 CIDRブロックを使用する必要があります。
  • VPCは、RFC1918 CIDRブロック（10.0.0.0/8、172.16.0.0/12、または192.168.0.0/16）を使用する必要があります。
  • VPCのCIDRブロックは、プライベートスペースのCIDR範囲と重複してはいけません。デフォルトの範囲は10.0.0.0/16、10.1.0.0/16、および172.17.0.0/16です。

プライベートスペースが稼働している状態で、ピアリング情報を取得する必要があります：

Shell

 

AWS アカウント ID（647xxxxxx317）とAWS VPC ID（vpc-e285ab73）をメモしてください。これらの情報を AWS データソースを管理するサードパーティー プロバイダーに提供する必要があります。その後、彼らは AWS コンソールまたは CLI を使用してピアリング接続を作成できます。彼らの操作は次のようになります：

Shell

 

これにより、ピアリングのリクエストが作成されます。プロバイダーがこれを行った後、Heroku 側で保留中のリクエストを表示できます：

Shell

 

以下のスクリーンショットでは、ピアリング接続の保留承認ステータスが表示されます。

ここから、ピアリング接続リクエストを承認できます：

Shell

 

リクエストのステータスをもう一度確認します：

Shell

 

ピアリング接続がアクティブであることがわかります。

この時点で、Heroku プライベートスペースで実行されているアプリは、AWS データソースに問題なくアクセスできます。

結論

人生において残念な真実は、関係が長続きすることと同じくらい、失敗することもあるということです。これは人間にも、テクノロジーにも当てはまります。

テクノロジーの意思決定に関しては、時には状況や必要性の変化が異なる方向に進むよう促します。時には、うまくいかないこともあります。そして、こうした状況では、既存の実装を解除することが最も大きな課題となることがよくあります — 永続データへのアクセスを失うことなく。

幸いなことに、Herokuは既存のクラウドベースのソリューションから徐々に移行するための解決策を提供しており、外部ホストされたデータにアクセスを維持しながら可能にしています。AWSとのVPCピアリングの簡単な統合により、レガシー実装に残る必要があるリソースにアクセスできます。あなたが進んでいく一方で、残りの部分が移動したとしても、

このアプローチを取ることで、新しいサービスが消費者へのサービス中断なしに繁栄することができます。

Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out