🥇サイバーパンク風味のクラウドサービス誕生の歴史

IT の分野で働いていると、システムには独自の性格があることに気づき始めます。柔軟であったり、沈黙であったり、風変わりであったり、厳格であったりします。それらは引き付けることも反発することもできます。いずれにせよ、あなたは彼らと「交渉」し、「落とし穴」の間を巧みに行き来し、彼らの相互作用の連鎖を構築する必要があります。

そこで私たちはクラウドプラットフォームを構築する光栄に浴しましたが、そのためにはいくつかのサブシステムに協力してもらう必要がありました。幸いなことに、私たちには「API 言語」、直接の人材、そして多くの熱意があります。

この記事は技術的には本格的なものではありませんが、クラウドの構築中に遭遇した問題について説明します。私は、システムとの共通言語をどのように探したのか、そしてそこから何が生まれたのかについて、軽い技術的なファンタジーの形で私たちの軌跡を説明することにしました。

猫さんへようこそ。

旅の始まり

少し前、私たちのチームはクライアント向けにクラウドプラットフォームを立ち上げるという任務を負っていました。当社には、管理サポート、リソース、ハードウェアスタックがあり、サービスのソフトウェア部分を実装するためのテクノロジーを自由に選択できました。

また、次のような多くの要件もありました。

このサービスには便利な個人アカウントが必要です。
プラットフォームは既存の請求システムに統合する必要があります。
ソフトウェアとハードウェア: OpenStack + タングステンファブリック (Open Contrail)。当社のエンジニアはこれを非常にうまく「調理」することを学びました。

Habra コミュニティにご興味があれば、チームがどのように編成され、個人アカウントのインターフェースが開発され、デザイン上の決定が行われたかについては、またの機会にお話しします。
使用することにしたツールは次のとおりです。

Python + Flask + Swagger + SQLAlchemy - 完全に標準的な Python セット。
フロントエンド用の Vue.js。
AMQP 経由で Celery を使用してコンポーネントとサービス間の対話を行うことにしました。

Python選びに関する疑問を想定して解説します。この言語は当社でニッチな地位を確立しており、小さいながらも文化がこの言語を中心に発展してきました。そこで、これをベースにサービスの構築を開始することにしました。さらに、このような問題の開発速度は多くの場合決定的です。

それでは、知り合いを始めましょう。

Silent Bill - 請求

私たちはこの男のことを長い間知っています。彼はいつも私の隣に座って、黙って何かを数えていました。時にはユーザーのリクエストを私たちに転送したり、クライアントの請求書を発行したり、サービスを管理したりしました。普通の努力家。確かに、困難はありました。彼は寡黙で、時には思慮深く、自分の考えだけを考えていることがよくあります。

請求は、私たちが最初に友達になろうとしたシステムです。そして最初に直面した困難は、サービスの処理時でした。

たとえば、タスクが作成または削除されると、内部の請求キューに入ります。したがって、サービスを使用した非同期作業のシステムが実装されます。サービスタイプを処理するには、タスクをこのキューに「入れる」必要がありました。そしてここで、ドキュメントの不足という問題に遭遇しました。

ソフトウェア API の説明から判断すると、この問題はまだ解決可能ですが、リバースエンジニアリングを行う時間がなかったため、ロジックを外部に取り出し、RabbitMQ の上にタスクキューを編成しました。サービスに対する操作はクライアントによって個人アカウントから開始され、バックエンドで Celery の「タスク」に変わり、請求側と OpenStack 側で実行されます。 Celery を使用すると、タスクの管理、繰り返しの整理、ステータスの監視が非常に便利になります。たとえば、「セロリ」について詳しく読むことができます。ここで.

また、お金が足りなくなったプロジェクトは、請求によって停止されることはありませんでした。開発者とのコミュニケーションの結果、統計を計算するとき (そしてまさにこの種のロジックを実装する必要がある)、停止ルールの複雑な相互関係があることがわかりました。しかし、これらのモデルは私たちの現実にはあまり適合しません。また、Celery 上のタスクを通じてこれを実装し、サービス管理ロジックをバックエンド側に取り込みました。

上記の両方の問題により、コードが少し肥大化したため、将来的には、タスクを処理するロジックを別のサービスに移動するためにリファクタリングする必要があります。このロジックをサポートするには、ユーザーとそのサービスに関する情報をテーブルに保存する必要もあります。

もう一つの問題は沈黙です。

Billy はいくつかの API リクエストに対して黙って「OK」と答えます。これは、たとえば、テスト中に約束された支払いを行った場合に当てはまります (これについては後で詳しく説明します)。リクエストは正しく実行され、エラーは見られませんでした。

UI を通じてシステムを操作しながら、ログを調べる必要がありました。請求自体も同様のリクエストを実行し、スコープを特定のユーザー (管理者など) に変更し、それを su パラメーターで渡すことが判明しました。

一般に、ドキュメントのギャップや API の小さな欠陥にもかかわらず、すべてが非常にうまくいきました。ログの構造と何を探すべきかを理解していれば、負荷が高くてもログを読み取ることができます。データベースの構造は凝っていますが、非常に論理的であり、ある意味では魅力的ですらあります。

要約すると、対話段階で遭遇した主な問題は、特定のシステムの実装機能に関連しています。

何らかの形で私たちに影響を与えた文書化されていない「機能」。
クローズドソース (請求は C++ で記述されている) であるため、結果として、「試行錯誤」以外の方法で問題 1 を解決することは不可能です。

幸いなことに、この製品にはかなり広範な API があり、次のサブシステムを個人アカウントに統合しました。

テクニカルサポートモジュール - 個人アカウントからのリクエストは、サービスクライアントに対する透過的な請求に「プロキシ」されます。
財務モジュール - 現在の顧客に請求書を発行し、償却を行い、支払書類を生成することができます。
サービス制御モジュール - このために、独自のハンドラーを実装する必要がありました。システムの拡張性が私たちに影響を与え、私たちはビリーに新しいタイプのサービスを「教えました」。
ちょっと面倒だったけど、いずれにせよ、ビリーと私は仲良くなれると思う。

タングステンフィールドを歩く – タングステンファブリック

タングステンフィールドには何百ものワイヤーが点在し、何千ビットもの情報を通過させます。情報は「パケット」に収集され、解析され、まるで魔法のように複雑なルートが構築されます。

これは、私たちが友達になる必要があった XNUMX 番目のシステムである Tungsten Fabric (TF) (以前は OpenContrail) のドメインです。そのタスクは、ネットワーク機器を管理し、ユーザーである私たちにソフトウェアの抽象化を提供することです。 TF - SDN は、ネットワーク機器を操作する複雑なロジックをカプセル化します。このテクノロジー自体については、たとえば、次のような優れた記事があります。ここで.

このシステムは、Neutron プラグインを介して OpenStack (後述) と統合されます。

OpenStack サービスの相互作用。

運用部門の人たちがこのシステムを私たちに紹介してくれました。当社はシステムの API を使用して、サービスのネットワークスタックを管理します。まだ深刻な問題や不便は発生していませんが (OE の人々のことを代弁することはできません)、相互作用にいくつかの奇妙な点がありました。

XNUMX つ目は次のようになります。SSH 経由で接続するときに大量のデータをインスタンスコンソールに出力する必要があるコマンドは単に接続を「切断」しましたが、VNC 経由ではすべてが正しく機能しました。

この問題に詳しくない人にとっては、この問題は非常に奇妙に見えます。ls /root は正しく動作しますが、たとえば、top は完全に「フリーズ」します。幸いなことに、私たちは以前にも同様の問題に遭遇したことがあります。これは、計算ノードからルーターまでのルート上の MTU を調整することによって決定されました。ちなみに、これはTFの問題ではありません。

次の問題がすぐそこまで迫っていた。ある「美しい」瞬間に、ルーティングの魔法はそのまま消えてしまいました。 TF は、機器上のルーティングの管理を停止しました。

私たちは管理者レベルから Openstack を使用し、その後、必要なユーザーレベルに移行しました。 SDN は、アクションを実行するユーザーのスコープを「ハイジャック」しているように見えます。実際、TF と OpenStack の接続には同じ管理者アカウントが使用されます。使い手に切り替わった段階で「魔法」は消えた。システムを操作するために別のアカウントを作成することが決定されました。これにより、統合機能を中断することなく作業できるようになりました。

シリコン生命体 - OpenStack

奇妙な形をしたシリコンの生き物がタングステンフィールドの近くに住んでいます。何よりも、一振りで我々を押しつぶしてしまうほど大きくなりすぎた子供のように見えますが、彼からは明らかな攻撃性が発せられません。それは恐怖を引き起こすものではありませんが、その大きさが恐怖を引き起こします。周囲で起こっていることの複雑さも同様です。

OpenStack は当社のプラットフォームの中核です。

OpenStack にはいくつかのサブシステムがあり、現在、Nova、Glance、Cinder を最も積極的に使用しています。それぞれに独自の API があります。 Nova はコンピューティングリソースとインスタンスの作成を担当し、Cinder はボリュームとそのスナップショットの管理を担当し、Glance は OS テンプレートとそのメタ情報を管理するイメージサービスです。

各サービスはコンテナ内で実行され、メッセージブローカーは「白いウサギ」である RabbitMQ です。

このシステムは私たちに最も予期せぬトラブルを引き起こしました。

そして、追加のボリュームをサーバーに接続しようとしたときに、最初の問題がすぐに発生しました。 Cinder API は、このタスクの実行をきっぱりと拒否しました。より正確に言うと、OpenStack 自体を信じれば、接続は確立されますが、仮想サーバー内にディスクデバイスが存在しません。

私たちは回り道をすることにし、Nova API に同じアクションをリクエストしました。その結果、デバイスは正しく接続され、サーバー内でアクセスできるようになります。この問題は、ブロックストレージが Cinder に応答しない場合に発生するようです。

ディスクを扱うときに、別の困難が待ち構えていました。システムボリュームをサーバーから切断できませんでした。

繰り返しになりますが、OpenStack 自体が接続を破壊したことを「誓約」し、ボリュームを個別に正しく操作できるようになりました。しかし、API はディスク上で操作を実行することを断固として望んでいませんでした。

ここでは特に争うことはせず、サービスのロジックに対する見方を変えることにしました。インスタンスがある場合は、システムボリュームも存在する必要があります。したがって、ユーザーは「サーバー」を削除せずにシステムの「ディスク」を削除したり無効にしたりすることはできません。

OpenStack は、独自の対話ロジックと華やかな API を備えたかなり複雑なシステムのセットです。私たちは、かなり詳細なドキュメントと、もちろん試行錯誤 (これがなければどうなるでしょうか) に助けられています。

試運転

昨年XNUMX月に試験打ち上げを実施した。主なタスクは、技術面と UX 面から戦闘モードでプロジェクトをテストすることでした。聴衆は選択的に招待され、テストは終了しました。ただし、Web サイトでテストへのアクセスをリクエストするオプションも残しています。

もちろん、テスト自体には面白い場面がなかったわけではありません。なぜなら、ここからが私たちの冒険が始まったばかりだからです。

まず、プロジェクトへの関心をやや誤って評価したため、テスト中にすぐに計算ノードを追加する必要がありました。クラスターの一般的なケースですが、ここでもいくつかのニュアンスがありました。 TF の特定のバージョンのドキュメントには、vRouter での動作がテストされたカーネルの特定のバージョンが示されています。私たちは、より新しいカーネルを使用してノードを起動することにしました。その結果、TF はノードからルートを受信できませんでした。緊急にカーネルをロールバックする必要がありました。

もう XNUMX つの興味深い点は、個人アカウントの「パスワード変更」ボタンの機能に関連しています。

セッションを操作しないように、JWT を使用して個人アカウントへのアクセスを整理することにしました。システムは多様で広範囲に分散しているため、請求からのセッションと OpenStack からのトークンを「ラップ」する独自のトークンを管理します。パスワードが変更されると、当然のことながら、ユーザーデータが無効になり、再発行する必要があるため、トークンは「無効になります」。

私たちはこの点を見失い、この作品をすぐに完成させるのに十分なリソースがありませんでした。テストを開始する直前に機能を削除する必要がありました。
現在、パスワードが変更された場合、ユーザーはログアウトされます。

こうした微妙な違いにもかかわらず、テストはうまくいきました。数週間で約300人が訪れた。私たちはユーザーの目で製品を確認し、実際に動作をテストして、質の高いフィードバックを収集することができました。

つづきます

私たちの多くにとって、これはこのような規模の初めてのプロジェクトです。私たちは、チームとして作業し、アーキテクチャと設計の決定を下す方法について、多くの貴重な教訓を学びました。複雑なシステムを少ないリソースで統合し、実稼働環境に導入する方法。

もちろん、コードとシステム統合のインターフェースの両方の点で取り組むべきことがあります。このプロジェクトはまだ始まったばかりですが、私たちはこれを信頼性が高く便利なサービスに成長させたいという野心でいっぱいです。

私たちはすでにシステムを説得することができています。ビルは、クローゼット内で集計、請求、ユーザーのリクエストを律儀に処理します。タングステンフィールドの「魔法」が安定した通信をもたらします。そして、OpenStack だけが時々気まぐれになり、「WSREP はアプリケーションで使用するノードをまだ準備していません」のようなことを叫びます。しかし、それはまったく別の話です...

このほどサービスを開始しました。
すべての詳細については、オンライン.

CLO開発チーム

便利なリンク集

OpenStackは

タングステン生地

出所： habr.com

サイバーパンク風味のクラウドサービス誕生の歴史

旅の始まり

Silent Bill - 請求

タングステンフィールドを歩く – タングステンファブリック

シリコン生命体 - OpenStack

試運転

つづきます

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル