アマゾンウェブサービスの緊急再配置-2つのクライアントストーリー





ロックは、ロシア市場で働く多くのプロジェクトに影響を与えました。 以下は、お客様の緊急の移転の1つです。



4月19日、彼らはロシア連邦の領土のプロバイダーの一部によって、公共サービスのIPアドレスの1つがブロックされていることに気付きました。 4月20日、状況は悪化しました-サブネット全体にアクセスできなくなりました。 これにより、バックアップチャネルの1つであるテスト環境が削除され、メールサーバーの動作が部分的に中断されました。 IPアドレスを置き換え、他のデータセンターを介してトラフィックをプロキシすることで、問題を解決することができました。



これらすべてが深刻かつ長期間(より正確には、このようなリスクが生じたとき)であることが明らかになったとき、お客様の1つである国際的な処理会社であるTeko社は、クラウドにインスタンスをデプロイすることを決定しました。 彼らのCIOはより重要な連携サービスであり、ロシア連邦での存在感を高めました。 引用:



「ロシア連邦のクラウドは、ILVによってサービスがブロックされないことを顧客に保証します。 リソースが提供される速度は非常に重要でした。 すべてが十分に迅速に行われました。まず、ロシア連邦でのサービスの可用性のためにGEO DNSを追加し、ブロックされていないDCを介してトラフィックのプロキシを開始しました。 遅い部分はデータベースフェデレーションです。」



「私たちが使用している技術スタックには困難があり、新しいバージョンのstrongSwanの作業で問題に直面して、外部クラウドへの追加トンネルを構築する必要がありました。 非常に高価:コンピューティングリソースの直接支払いに加えて、いくつかのクラウドをサポートするための一時的なリソースのかなりの出費があり、必要なAmazonian / Googleサービスが不足しています。 その結果、追加のクラウドを使用して作業し、はるかに大きな財務コストを負担します。 追加の障害点があります。 問題の診断がより難しくなりました。 IaC(コードとしてのインフラストラクチャ)アプローチを使用します。これにより、Terraform、Ansible、Kubernetesに基づいた再現可能なインフラストラクチャを構築できました。 インフラストラクチャの展開は非常に迅速に進みました。」



セカンドストーリー



「彼らは、他の皆と同じように、ニュースから気づきました。 業務で使用している一部のサードパーティサービスが機能しなくなったか、誤動作し始めました。 たとえば、SlackおよびMavenリポジトリ。 これはビジネスに直接影響しませんでした。ロシア連邦のプロバイダーと長い間、ロシア連邦の顧客にサービスを提供するインフラストラクチャを保持してきました。 Technoservクラウドはかなり以前から知られており、それについての知識を蓄積してきました。



クラウドプロバイダーを選択する際には、サービスの品質と信頼性に加えて、法的問題が重要です。 ロシア連邦外のクラウドの場合の文書フローは非常に複雑であり、支払いは通貨管理と税の微妙さに関連しています。 企業がロシア連邦で事業を運営している場合、すべてのインフラストラクチャをロシア連邦で提供するのが最も簡単です。



私たちはロシア連邦のさまざまなプロバイダーと協力してきました。また、チームはAWSプラットフォームやIaaSの他の世界的リーダーとの幅広い経験があります。 クラウドプロバイダーからは、仮想マシンをレンタルするだけでなく、インフラストラクチャサポートを簡素化する次のような追加機能も期待しています。





Technoservの場合、リストされたすべての機能を見ましたが、これは私たちにとって重要な議論になりました。 さらにテストを行った結果、Technoservインフラストラクチャのパフォーマンスに大きなマージンがあり、インフラストラクチャのボトルネックを満たしてデバッグする技術サービスの要望が示されましたが、最終的にはそのようなことはなくなりました。 他のクラウドプロバイダーからいくつかのサービスを移行し、Technoservクラウドに既に新しいサービスを展開し始めました。



クラウドストレージを把握し、既存のネットワークインフラストラクチャに新しいサイトを構築するのに約1か月かかりました。



クラウドストレージの統合に問題がありました。おそらく、このようなモデルで最初にクラウドストレージを使用したのでしょう。 しかし、サポート作業には満足していました。同僚が主要な問題の解決を支援し、必要に応じてリポジトリの開発者を接続してエラーを修正しました。



その結果、ロシア連邦の主要なサイトになりました。 Apache SparkやApache Zeppelinなど、データ処理に使用する多くのツールを接続して、Technoservクラウドストレージを操作しました。 AWS S3 APIとの完全な互換性により、既存のライブラリを変更せずに使用できることに驚きました。 Sparkの場合、クラウドストレージを使用すると、速度と信頼性を失うことなく、HDFSクラスターが不要になり、コストを節約できます。



何が起こっているの?



閉塞のため、Amazonからロシアのクラウドへの移行の2番目の波が始まりました(最初の波は、個人データの保存と処理の新しい標準が始まったときであり、実際、ロシアの仮想化市場に弾みをつけました)。 新規顧客のほとんどは、S3オブジェクトストレージなどの最も互換性のあるサービスを必要としています。 ロシアでは、このサービスを提供しているクラウドプロバイダーは4つのみであり、専門家によると最も互換性があります(3つのS3プロバイダーがあったときに評価が行われたことに注意する必要があります)。



なぜVPNまたはプロキシではないのですか? 同じロックの観点からこのような構造を安定して維持することは非常に難しいからです。 一部のお客様は、インフラストラクチャをドイツのサーバーに移行するオプションを検討していましたが、ご存じのように、この運用ソリューションは役に立たなかった-同じHetznerがすぐにサブネット全体のロックのリストに入りました。



結果はロシアのクラウドに転送されます。 理由は非常にありふれたものです。Roskomnadzorはロシアの組織であるため、ロシア連邦の領土で最初にブロックを警告し、次に対策を講じてからブロックする時間を与えます。 つまり、ブロックが他の顧客に影響を与えない「いじめ」サブネットを選択するか、パブリッククラウドの他のクライアントとの干渉でアイテムのアクティビティを停止するように依頼することができます。



特定の条件下では、Amazonよりも収益性が高いオープン価格があります。 こちらが価格表です。



物理的には、多くの組織的な理由で「悪夢」に陥ることはありません-裁判所命令が必要であり、これにはかなり時間がかかります。 しかし、私の同僚はこのことについて少し後で説明します。



かなり柔軟な量子化を行っているため、状況が停止した場合は、AWSに切り替えてバックアップ展開の契約を維持できます。 停止しない場合は、Amazon互換のクラウドが回転しているロシアのデータセンターがあります。 アーキテクチャとボリュームに応じて、最小限のダウンタイムで、またはダウンタイムなしで迅速に移動し、上昇するのに役立ちます。



現在、小規模プロジェクトを移動する最も一般的なケースは、バックアップ、停止、およびバックアップからの展開、または最初のインスタンスのバックアップ、展開、同期、および無効化です。



すべての質問については、メールに書いてください:MBlinov@technoserv.com



All Articles