Kubernetes と自動化により XNUMX 時間でクラウドに移行する方法

URUS 社は、ベアメタルや Google Cloud での独立したデプロイなど、さまざまな形式で Kubernetes を試し、その後、そのプラットフォームを Mail.ru クラウド ソリューション (MCS) クラウドに移行しました。 Igor Shishkin は、新しいクラウド プロバイダーをどのように選択し、どのようにして記録的な XNUMX 時間でそこに移行できたかを語ります (t3ran)、URUS の上級システム管理者。

ウルスって何をするの？

都市環境の質を改善するには多くの方法がありますが、その XNUMX つは環境に優しい都市にすることです。 これはまさに URUS (スマート デジタル サービス会社) が取り組んでいることです。 ここでは、企業が重要な環境指標を監視し、環境への悪影響を軽減するのに役立つソリューションを導入しています。 センサーは空気の組成、騒音レベル、その他のパラメーターに関するデータを収集し、それらを統合された URUS-Ekomon プラットフォームに送信して分析し、推奨事項を作成します。

URUS の内部からの仕組み

URUS の典型的な顧客は、住宅地またはその近くにある企業です。 これは、工場、港、鉄道車両基地、またはその他の施設である可能性があります。 当社のクライアントがすでに警告を受けている場合、環境汚染で罰金を科された場合、または騒音を減らし、有害な排出量を削減したい場合は、当社に来てください。当社はすでに環境モニタリングのための既製のソリューションを提供しています。

H2S 濃度監視グラフは、近くの工場からの定期的な夜間排出量を示しています

URUS で使用するデバイスには、環境状況を評価するために特定のガスの含有量、騒音レベル、その他のデータに関する情報を収集するいくつかのセンサーが含まれています。 センサーの正確な数は、常に特定のタスクによって決まります。

測定の詳細に応じて、センサーを備えたデバイスを建物の壁、電柱、その他の任意の場所に配置できます。 このような各デバイスは情報を収集し、集約してデータ受信ゲートウェイに送信します。 そこでデータを長期保存用に保存し、その後の分析のために前処理します。 分析の結果として得られるものの最も単純な例は、AQI とも呼ばれる大気質指数です。

並行して、他の多くのサービスが当社のプラットフォーム上で動作しますが、それらは主にサービスの性質のものです。 たとえば、通知サービスは、監視対象パラメータ (CO2 含有量など) のいずれかが許容値を超えた場合にクライアントに通知を送信します。

データの保存方法。 ベアメタル上の Kubernetes の物語

URUS 環境モニタリング プロジェクトには、いくつかのデータ ウェアハウスがあります。 XNUMX つは「生」データ、つまりデバイス自体から直接受信したデータを保持します。 このストレージは古いカセットテープのような「磁気」テープであり、すべてのインジケーターの履歴が含まれています。 XNUMX 番目のタイプのストレージは、前処理されたデータ、つまりセンサー間の接続やデバイス自体の測定値、組織との所属、場所などに関するメタデータで強化されたデバイスからのデータに使用されます。この情報により、特定のインジケーターがどのように機能するかを動的に評価できます。一定期間を経て変化したもの。 当社では、特に「生」データ ストレージをバックアップとして、また必要に応じて前処理されたデータを復元するために使用します。

数年前、ストレージの問題を解決しようとしたとき、プラットフォームには Kubernetes と OpenStack の XNUMX つの選択肢がありました。 しかし、後者は非常に巨大に見えるため (これはそのアーキテクチャを見て確認してください)、私たちは Kubernetes に落ち着きました。 もう XNUMX つの賛成意見は、比較的シンプルなソフトウェア制御、リソースに応じてハードウェア ノードさえもより柔軟にカットできる機能でした。

Kubernetes 自体を習得するのと並行して、私たちはデータを保存する方法も研究し、すべてのストレージを Kubernetes の独自のハードウェア上に保持し、優れた専門知識を得ました。 当時、ステートフル ストレージ、監視システム、CI/CD など、私たちが使用していたものはすべて Kubernetes 上にありました。 Kubernetes は私たちにとってオールインワンのプラットフォームになりました。

しかし、私たちは Kubernetes をサービスとして扱いたいと考えており、そのサポートや開発には携わりたくないのです。 さらに、ベアメタルで維持するのにかかるコストが気に入らず、常に開発が必要でした。 たとえば、最初のタスクの XNUMX つは、Kubernetes Ingress コントローラーを組織のネットワーク インフラストラクチャに統合することでした。 これは、特に当時、DNS レコードや IP アドレスの割り当てなどのプログラムによるリソース管理の準備が整っていなかったことを考えると、面倒な作業です。 その後、外部データ ストレージの実験を開始しました。 PVC コントローラーの実装には決して着手できませんでしたが、それでも、これが専任の専門家を必要とする広範な作業領域であることが明らかになりました。

Google Cloud Platform への切り替えは一時的な解決策です

私たちはこのままではいけないと悟り、データをベアメタルから Google Cloud Platform に移行しました。 実際、当時、ロシアの企業にとって興味深い選択肢はあまりありませんでした。Google Cloud Platform のほかに同様のサービスを提供していたのは Amazon だけでしたが、それでも Google のソリューションに落ち着きました。 そして、Google 自体が本番環境における一種の PoC Kubernetes であるという事実は言うまでもなく、アップストリームに近い、より経済的に収益性が高いように思えました。

私たちの顧客ベースが拡大するにつれて、最初の大きな問題が目前に迫ってきました。 個人データを保存する必要があるとき、私たちは選択を迫られました。Google と協力してロシアの法律に違反するか、ロシア連邦で代替手段を探すかのどちらかです。 全体として、この選択は予測可能でした。 🙂

私たちが考えた理想のクラウドサービス

検索を開始した時点で、将来のクラウド プロバイダーから何を取得したいかはすでにわかっていました。 私たちが探していたサービス:

• 高速かつ柔軟。 これにより、いつでも新しいノードをすばやく追加したり、何かをデプロイしたりできます。
• 安価な。 私たちはリソースが限られていたため、財政的な問題について非常に心配していました。 Kubernetes を使用したいことはすでにわかっていましたが、このソリューションの使用効率を高めるか、少なくとも維持するためにコストを最小限に抑えることが課題となりました。
• 自動化。 私たちは、マネージャーや電話をかけたり、緊急モードで数十のノードを手動で起動する必要がある状況を必要とせずに、API を介してサービスを操作することを計画しました。 私たちのプロセスのほとんどは自動化されているため、クラウド サービスにも同じことを期待していました。
• ロシア連邦にサーバーがある。 もちろん、私たちはロシアの法律と同じ152-FZに準拠するつもりでした。

当時、ロシアには Kubernetes aaS プロバイダーがほとんどなく、プロバイダーを選択する際には優先順位を妥協しないことが重要でした。 私たちが協力し始め、現在も協力している Mail.ru クラウド ソリューション チームは、API サポートと Horizo​​n を含む便利なコントロール パネルを備えた完全に自動化されたサービスを提供してくれました。これを使用すると、任意の数のノードをすぐに増やすことができました。

XNUMX 時間で MCS に移行できた方法

こうした動きの中で多くの企業は困難や挫折に直面しますが、当社の場合はそのようなことはありませんでした。 私たちは幸運でした。移行が始まる前にすでに Kubernetes に取り組んでいたため、XNUMX つのファイルを修正するだけで、新しいクラウド プラットフォームである MCS 上でサービスを開始しました。 思い出してもらいたいのですが、その時までに私たちはついにベアメタルを卒業し、Google Cloud Platform 上で生活していました。 したがって、移動自体には XNUMX 時間もかかりませんでした。さらに、デバイスからデータをコピーするのにもう少し時間がかかりました (約 XNUMX 時間)。 当時、私たちはすでに Spinnaker (継続的デリバリーを提供するマルチクラウド CD サービス) を使用していました。 また、すぐにそれを新しいクラスターに追加し、通常どおり動作し続けました。

開発プロセスと CI/CD の自動化のおかげで、URUS の Kubernetes は XNUMX 人の専門家 (それが私です) によって処理されます。 ある段階では、別のシステム管理者が私と協力してくれましたが、その後、メインルーチンはすべて自動化されており、メイン製品の側にますます多くのタスクがあり、これにリソースを割り当てることが理にかなっていることが判明しました。

幻想を持たずに協力を開始して以来、クラウドプロバイダーから期待していた通りの結果を得ることができました。 インシデントがあったとしても、そのほとんどは技術的なものであり、サービスの比較的新しいものによって簡単に説明できるものでした。 重要なことは、MCS チームが欠点をすぐに解消し、メッセンジャーでの質問に迅速に応答することです。

私の経験を Google Cloud Platform と比較すると、Google Cloud Platform の場合は、フィードバック ボタンがどこにあるのかさえわかりませんでした。その必要がまったくなかったからです。 そして、何か問題が発生した場合には、Google自体が一方的に通知を送りました。 しかし、MCS の場合、地理的にも精神的にもロシアの顧客に可能な限り近いことが大きな利点だと思います。

将来のクラウドの利用について私たちはどう考えるか

現在、私たちの仕事は Kubernetes と密接に結びついており、インフラストラクチャ タスクの観点から見ると Kubernetes が完全に適しています。 したがって、そこからどこにも移行するつもりはありませんが、日常的なタスクを簡素化し、新しいタスクを自動化し、サービスの安定性と信頼性を高めるために、常に新しいプラクティスとサービスを導入しています...現在、Chaos Monkey サービス (具体的には、Chaos Monkey サービス) を開始しています。 、chaoskube を使用しますが、コンセプトは変わりません: )、これはもともと Netflix によって作成されました。 Chaos Monkey は、ランダムな時間にランダムな Kubernetes ポッドを削除するという単純なことを 1 つ実行します。 これは、サービスがインスタンス数 n–XNUMX で正常に動作するために必要なため、あらゆる問題に備えてトレーニングします。

今では、同じクラウド プラットフォームであるサードパーティ ソリューションを使用することが、若い企業にとって唯一の正しいことだと考えています。 通常、旅の開始時点では人的・経済的リソースが限られており、独自のクラウドやデータセンターを構築して維持するには費用も労力もかかりすぎます。 クラウド プロバイダーを使用すると、これらのコストを最小限に抑えることができ、サービスの運用に必要なリソースをその場ですぐにクラウド プロバイダーから入手し、事後的にこれらのリソースの料金を支払うことができます。 URUS 社に関しては、今のところクラウドの Kubernetes に忠実であり続けます。 しかし、地理的に拡大したり、特定の機器に基づいたソリューションを実装したりする必要があるかもしれません。 あるいは、古き良き時代のように、消費されるリソースの量によって、ベアメタル上の独自の Kubernetes が正当化されるかもしれません。 🙂

クラウド サービスの利用から学んだこと

私たちはベアメタルで Kubernetes を使い始めましたが、そこでもそれはそれで良かったです。 しかし、その強みはまさにクラウド内の aaS コンポーネントとして明らかになりました。 目標を設定してすべてを可能な限り自動化すれば、ベンダー ロックインを回避でき、クラウド プロバイダー間の移動には数時間かかりますが、神経細胞は残ります。 私たちは他の企業にもアドバイスできます。リソースが限られていて開発速度が最大で独自の (クラウド) サービスを立ち上げたい場合は、今すぐクラウド リソースをレンタルして開始し、Forbes に記事が掲載された後にデータ センターを構築してください。

出所： habr.com