孤立したサービス: (マイクロ) サービス アーキテクチャの欠点

Banki.ru ポータルの運営ディレクターである Andrey Nikolsky 氏は昨年のカンファレンスで講演しました DevOpsDays モスクワ 孤立したサービスについて: インフラストラクチャ内の孤立したサービスを特定する方法、孤立したサービスが悪い理由、孤立したサービスをどうするか、何も役に立たない場合の対処方法。

カットの下にはレポートのテキスト版が表示されます。

こんにちは、同僚です！ 私の名前は Andrey です。Banki.ru の運営責任者を務めています。

大規模なサービスもあれば、モノリシックなサービスもあれば、より古典的な意味でのサービスもあれば、非常に小規模なサービスもあります。 私の労農用語では、サービスが単純で小規模であれば、それはマイクロであり、あまり単純で小規模でない場合、それは単なるサービスであると言います。

サービスの長所

サービスの利点について簡単に説明します。

XNUMXつ目はスケーリングです。 サービス上ですぐに何かを実行して、本番環境を開始できます。 トラフィックを受信し、サービスのクローンを作成しました。 トラフィックが増え、それを複製して共存させています。 これは良いボーナスであり、原則として、私たちが始めたときは、なぜこれだけのことを行うのかということが私たちにとって最も重要なことであると考えられていました。

XNUMX つ目は、分離開発です。複数の開発チームがあり、各チームに数人の異なる開発者がいて、各チームが独自のサービスを開発する場合です。

チームの場合は微妙な違いがあります。 開発者は違います。 そして、例えば、 雪の結晶の人。 私がこれを初めて見たのはマキシム・ドロフェエフでした。 スノーフレークの人は、あるチームに所属していて、他のチームに所属していないことがあります。 このため、会社全体で使用されるさまざまなサービスが少し不均一になります。

写真を見てください。この人は優れた開発者で、手が大きく、たくさんのことができます。 主な問題は、これらの手がどこから来たのかということです。

サービスにより、さまざまなタスクにより適したさまざまなプログラミング言語を使用できるようになります。 サービスの中には、Go で作られたもの、Erlang で作られたもの、Ruby で作られたもの、PHP で作られたもの、Python で作られたものがあります。 一般に、非常に広範囲に拡張できます。 ここにもニュアンスがあります。

サービス指向アーキテクチャは主に DevOps に関するものです。 つまり、自動化がなければ、デプロイメントプロセスは存在せず、手動で構成した場合、構成はサービスインスタンスごとに変更される可能性があり、何かをするためにそこに行かなければならない場合、地獄に陥ることになります。

たとえば、20 個のサービスがあり、手動でデプロイする必要があるとします。20 個のコンソールがあり、忍者のように同時に「Enter」を押します。 あまり良くないですね。

テスト後のサービスがあり (もちろんテストがある場合)、本番環境で動作させるためにファイルを完成させる必要がある場合は、悪い知らせもあります。

あなたが特定の Amazon サービスに依存し、ロシアで働いているなら、XNUMX か月前には「周りはすべて燃えている、私は大丈夫、すべては涼しい」という経験をしていたはずです。

デプロイメントの自動化には Ansible、コンバージェンスには Puppet、デプロイメントの自動化には Bamboo、そしてそれらすべてを何らかの方法で記述するために Confluence を使用します。

このレポートは技術的な実装ではなく、インタラクションの実践に関するものであるため、これについては詳しく説明しません。

たとえば、サーバー上の Puppet は Ruby 2 で動作するが、一部のアプリケーションは Ruby 1.8 用に作成されており、連携して動作しないという問題が発生しました。 そこで何か問題が発生します。 そして、XNUMX 台のマシン上で複数のバージョンの Ruby を実行する必要がある場合、通常は問題が発生し始めます。

たとえば、私たちは各開発者に、私たちが持っているほぼすべてのもの、開発できるすべてのサービスが含まれるプラットフォームを提供します。これにより、開発者は隔離された環境を手に入れ、必要に応じてそれを壊したり構築したりできます。

何かをサポートする特別にコンパイルされたパッケージが必要になる場合があります。 かなり大変ですよ。 Docker イメージの重さが 45 GB であるというレポートを聞きました。 もちろん、Linux ではよりシンプルで、すべてが小さくなりますが、それでも十分なスペースはありません。

プロジェクトの XNUMX つの部分が XNUMX つのバージョンのライブラリに依存し、プロジェクトの別の部分が別のバージョンに依存し、ライブラリがまったく一緒にインストールされない場合、依存関係の競合が発生します。

私たちは PHP 5.6 でサイトやサービスを運営していますが、恥ずかしいと思いますが、何ができるでしょうか? これが私たちの唯一のサイトです。 PHP 7 にはサイトやサービスがあり、さらに多くのサイトやサービスが存在しますが、私たちはそれらを恥じることはありません。 そして、各開発者は自分の拠点を持っており、そこで喜んで見ています。

社内で XNUMX つの言語で執筆している場合、開発者ごとに XNUMX 台の仮想マシンが存在するのは普通のことのように思えます。 異なるプログラミング言語を使用している場合、状況はさらに悪化します。

これにサイトとサービスがあり、次に Go 用の別のサイト、Ruby 用のサイトが XNUMX つ、そしてその横に他の Redis がいくつかあります。 その結果、これらすべてがサポートのための大きなフィールドに変わり、常にその一部が壊れる可能性があります。

したがって、PHP フレームワークはまったく異なり、機能、コミュニティ、サポートが異なるため、プログラミング言語の利点をさまざまなフレームワークの使用に置き換えました。 また、サービスを作成して、それに対する準備がすでに整っているようにすることもできます。

各サービスには独自のチームがあります

数年間にわたって具体化した当社の主な利点は、各サービスに独自のチームが存在することです。 これは大規模なプロジェクトに便利で、ドキュメント作成にかかる時間を節約でき、マネージャーは自分たちのプロジェクトをよく知っています。

サポートからタスクを簡単に送信できます。 たとえば、保険サービスが破綻した。 そしてすぐに保険を扱うチームが修理に行きます。

アトミックなサービスが XNUMX つあれば、それにすぐに何かを組み込むことができるため、新しい機能がすぐに作成されます。

そして、あなたが自分のサービスを壊したとき、これは必然的に起こりますが、他の人のサービスには影響を与えていないので、他のチームからの情報を持っている開発者があなたのところに駆け寄って「ああ、そんなことはやめてください」とは言いません。

いつものように、ニュアンスがあります。 私たちのチームは安定しており、マネージャーはチームに釘付けです。 明確な文書があり、マネージャーはすべてを注意深く監視しています。 マネージャーがいる各チームには複数のサービスがあり、特定の能力点があります。

チームが浮いている場合 (私たちも時々これを使用します)、「スター マップ」と呼ばれる良い方法があります。

サービスと人々のリストがあります。 アスタリスクはその人がこのサービスの専門家であることを意味し、本はその人がこのサービスを研究していることを意味します。 その人の仕事は、小冊子をアスタリスクに変更することです。 そして、サービスの前に何も書かれていない場合、問題が始まりますが、それについてはさらに説明します。

孤立したサービスはどのように表示されますか?

最初の問題は、インフラストラクチャに孤立したサービスを導入する最初の方法は、従業員を解雇することです。 タスクが評価される前にビジネスで締め切りを守れた人はいるでしょうか? 締め切りが迫っており、文書化する時間がまったくない場合もあります。 「サービスを本番環境に引き渡す必要があります。その後、サービスを追加します。」

チームが小さい場合は、XNUMX 人の開発者がすべてを作成し、残りの開発者は待機していることがよくあります。 「基本的なアーキテクチャは私が書きました。インターフェイスを追加しましょう。」 そしてある時点で、たとえばマネージャーが退職します。 そして、マネージャーが去り、新しいマネージャーがまだ任命されていないこの期間中、開発者自身がサービスの行き先とそこで何が起こっているかを決定します。 そして、ご存知のとおり (スライドを数枚前に戻しましょう)、チームによってはスノーフレークの人材が存在し、場合によってはスノーフレーク チームのリーダーが存在します。 それから彼は辞めて、私たちは孤立したサービスを受けることになりました。

同時に、サポートやビジネスからのタスクは消えることなく、バックログに残ります。 サービスの開発中にアーキテクチャ上のエラーがあった場合、それらもバックログに残ります。 サービスは徐々に悪化しています。

孤児を特定するにはどうすればよいですか?

このリストは状況をよく説明しています。 自社のインフラストラクチャについて何かを学んだ人はいるでしょうか?

文書化された回避策について: サービスはあり、一般的には機能します。その操作方法については XNUMX ページのマニュアルがありますが、内部でどのように機能するかは誰も知りません。

あるいは、たとえば、ある種のリンク短縮機能もあります。 たとえば、現在、さまざまなサービスのさまざまな目的で XNUMX つのリンク短縮ツールが使用されています。 これらは単なる結果です。

これからは私が当然のキャプテンになります。 何をすべきでしょうか? まず、サービスを別のマネージャー、別のチームに移す必要があります。 チームリーダーがまだ辞めていない場合、この別のチームには、サービスが孤児のようなものであることを理解したときに、そのサービスについて少なくとも何かを理解している人を含める必要があります。

重要なことは、移管手順を血書で書かなければならないことです。 私たちの場合、すべてが機能する必要があるため、通常はこれを監視しています。 マネージャーは、それを迅速に提供する必要があり、後でそれがどうなるかは、彼らにとってもはやそれほど重要ではありません。

孤児を作る次の方法は、「外注して、そのほうが早いです。その後、チームに引き継ぎます。」です。 誰もがチーム内でいくつかの計画、つまり順番を持っていることは明らかです。 多くの場合、企業顧客は、アウトソーサーが会社の技術部門と同じことを行うと考えています。 動機は異なりますが。 アウトソーシングには奇妙な技術的解決策と奇妙なアルゴリズム的解決策があります。

たとえば、さまざまな予期せぬ場所に Sphinx を配置したサービスがありました。 私が何をしなければならなかったのかは後で話します。

アウトソーシング業者は独自に作成したフレームワークを持っています。 これは、以前のプロジェクトからコピー＆ペーストした単なる PHP であり、あらゆる種類のものを見つけることができます。 展開スクリプトは、ファイル内の複数の行を変更するために複雑な Bash スクリプトを使用する必要があり、これらの展開スクリプトが 8 番目のスクリプトによって呼び出される場合に大きな欠点になります。 その結果、デプロイメント システムを変更し、別のものを選択し、ホップしましたが、サービスは機能しません。 異なるフォルダー間にさらに XNUMX つのリンクを配置する必要があるためです。 あるいは、XNUMX 個のレコードは機能するが、XNUMX 万個のレコードが機能しなくなることが起こります。

引き続きキャプテンを務めさせていただきます。 外部委託サービスの受け入れは必須の手続きです。 外部委託サービスが到着したものの、どこにも受け入れられなかったという人はいますか? もちろん、これは孤立したサービスほど人気はありませんが、それでも人気があります。

サービスを確認し、サービスを見直し、パスワードを変更する必要があります。 彼らが私たちにサービスを提供したとき、「ログイン == 'admin' && パスワード == 'admin'...」という管理パネルがあり、それがコードに直接書かれていることがありました。 私たちは座って考えていますが、2018 年にこれを書いている人はいるでしょうか？

ストレージ容量のテストも必要です。 このサービスをどこかで運用する前に、XNUMX 万件のレコードで何が起こるかを検討する必要があります。

改善のためにサービスを送ることは恥ずかしいことではありません。 「このサービスは受け付けません。タスクが 20 個あります。それを実行してから受け付けます」と言った場合、これは正常です。 あなたがマネージャーを設置しているという事実や、ビジネスがお金を無駄にしているという事実によって、あなたの良心が傷つけられるべきではありません。 そうすれば、企業はさらに支出を増やすことになります。

パイロットプロジェクトを外部委託することを決定したときのケースがありました。

予定通りに納品され、これが唯一の品質基準でした。 それが、私たちが別のパイロット プロジェクトを作成した理由です。それはもはやパイロットですらないものでした。 これらのサービスは受け入れられ、管理上の手段を通じて、「これがあなたのコードです、ここがチームです、ここがあなたのマネージャーです」と言われました。 実際、このサービスはすでに収益を上げ始めています。 同時に、実際には、彼らはまだ孤児であり、誰も彼らがどのように働いているかを理解しておらず、マネージャーは彼らの仕事を拒否しようと最善を尽くしています。

もう XNUMX つの素晴らしいコンセプトがあります。それはゲリラ開発です。 ある部門 (通常はマーケティング部門) が仮説をテストしたいと考え、サービス全体をアウトソーシングするように注文する場合。 トラフィックが流入し始め、彼らは書類を閉じ、請負業者と書類に署名し、業務を開始してこう言います。「皆さん、ここにはサービスがあります。すでにトラフィックがあり、お金がもたらされます。受け入れましょう。」 私たちは「オッパ、どうしてそんなことがあるの？」って感じでした。

そして、孤立したサービスを取得するもう XNUMX つの方法: あるチームが突然負荷がかかっていることに気付いたとき、経営陣は「このチームのサービスを別のチームに移しましょう。負荷は小さいです。」と言います。 そして、それを第三チームに移管し、監督を変えることになる。 そして最終的にはまた孤児が生まれるのです。

孤児の問題は何ですか？

知らない人はいないでしょうが、これはスウェーデンで建造された戦艦ワサで、進水後 5 分で沈没したことで有名です。 ちなみに、スウェーデン国王はこのために誰も処刑しませんでした。 この船は、そのような船の作り方を知らなかった XNUMX 世代の技術者によって建造されました。 自然な効果。

ちなみに、船はもっと悪い形で沈没した可能性があります。たとえば、嵐のどこかで王がすでに船に乗っていたときです。 そして、アジャイルによれば、早期に失敗するのは良いことだというので、彼はすぐに溺死しました。

早期に失敗しても、通常は問題はありません。 たとえば、承認中に改訂のために送信されました。 しかし、資金を投資した段階ですでに失敗してしまった場合、問題が発生する可能性があります。 ビジネスで言うところの「結果」。

孤立したサービスが危険な理由:

• 突然サービスが停止する場合があります。
• サービスの修復に時間がかかるか、まったく修復されない。
• 安全上の問題。
• 改善やアップデートに関する問題。
• 重要なサービスが故障すると、会社の評判は傷つきます。

孤立したサービスをどうするか?

もう一度何をするかを繰り返します。 まず、文書がなければなりません。 Banki.ru での 7 年間の経験から、テスターは開発者の言葉を鵜呑みにしてはいけないし、運用は全員の言葉を鵜呑みにしてはいけないということを学びました。 確認する必要があります。

次に、あまり評判の良くないサービスには、誰も言わなかった依存関係が含まれている場合があるため、相互作用図を書く必要があります。 たとえば、開発者は、一部の Yandex.Maps または Dadata のキーにサービスをインストールしました。 無料の制限を使い果たし、すべてが壊れ、何が起こったのかまったくわかりません。 このようなレイクはすべて説明する必要があります。サービスは Dadata、SMS、その他のものを使用します。

第三に、技術的負債への取り組みです。 何らかの松葉杖をついたり、サービスを受け入れたりして、何かをする必要があると言うときは、それが確実に行われるようにする必要があります。 なぜなら、その小さな穴はそれほど小さくないことが判明し、そこから落ちてしまうかもしれないからです。

建築に関するタスクでは、スフィンクスについての話をしました。 サービスの 50 つは、リストの入力に Sphinx を使用していました。 ページ分割されたリストですが、毎晩インデックスが再作成されました。 それは 5 つのインデックスから組み立てられていました。40 つの大きなインデックスは毎晩インデックスされ、もう XNUMX つはネジで固定された小さなインデックスでした。 毎日、爆撃があるかどうかの確率が XNUMX% であるため、計算中に指数がクラッシュし、メイン ページでのニュースの更新が停止しました。 最初はインデックスの再作成に XNUMX 分かかりましたが、その後インデックスが増加し、ある時点でインデックスの再作成に XNUMX 分かかり始めました。 これを切り出したとき、私たちは安堵のため息をつきました。もう少し時間が経てば、インデックスがフルタイムで再作成されることは明らかだったからです。 これは私たちのポータルにとっては失敗でしょう。XNUMX 時間ニュースがありません。それだけです。ビジネスは停止しました。

孤立したサービスの使用を計画する

実際、DevOps は通信に関するものであるため、これを行うのは非常に困難です。 あなたは同僚と良好な関係を保ちたいと思っていますが、同僚やマネージャーに規制を課す場合、彼らはそのようなことをする人々に対して相反する感情を抱くかもしれません。

これらすべての点に加えて、もう XNUMX つ重要な点があります。それは、特定の担当者が、特定のサービスごと、展開手順の特定のセクションごとに責任を負わなければならないということです。 人がいなくて、この問題全体を研究するために他の人を集めなければならない場合、それは困難になります。

これらすべてが役に立たず、孤立したサービスがまだ孤児のままで、誰もそれを引き継ぎたがらず、ドキュメントが書かれておらず、このサービスに呼び出されたチームが何もしようとしない場合、簡単な方法があります - やり直すすべてを。

つまり、サービスの要件を新たに取り上げ、奇妙な技術的ソリューションを使用せずに、より優れたプラットフォーム上で、より優れた新しいサービスを作成します。 そして戦闘中にそこに移行します。

Yii 1 でサービスを利用したときに、Yii 1 でうまく書ける開発者が不足しているため、これ以上開発できないことがわかったという状況がありました。すべての開発者は Symfony XNUMX でうまく書けます。 何をするか？ 私たちは時間を割り当て、チームを割り当て、マネージャーを割り当て、プロジェクトを書き直し、トラフィックをスムーズに切り替えました。

その後、古いサービスを削除できます。 これは、構成管理システムから一部のサービスを取得して削除し、その後、開発者に痕跡が残らないように、実稼働中のすべての車両が無効になっていることを確認する必要がある場合に使用する、私のお気に入りの手順です。 リポジトリは Git 内に残ります。

私が話したかったのはこれだけです。議論する準備はできています。テーマはホリバルです。多くの人がその中で泳ぎました。

スライドには言語を統一したと書かれていました。 例としては、写真のサイズ変更があります。 本当に XNUMX つの言語に厳密に制限する必要があるのでしょうか? なぜなら、PHP での画像のサイズ変更は、実際には Golang で行うことができるからです。

実際、他の実践と同様、これはオプションです。 おそらく場合によっては、それは望ましくないことさえあります。 しかし、50 人規模の会社に技術部門があり、そのうち 45 人が PHP のスペシャリストで、残りの 3 人が Python、Ansible、Puppet などを知っている DevOps で、そのうちの XNUMX 人だけがいくつかの機能を記述していることを理解する必要があります。 Go の画像サイズ変更サービスのようなもので、サービスが終了すると専門知識も伴います。 同時に、特に希少な場合は、この言語に精通した市場固有の開発者を探す必要があります。 つまり、組織の観点からすると、これは問題です。 Devops の観点から見ると、サービスのデプロイに使用する既製の Playbook セットを複製するだけでなく、それらを最初から書き直す必要があります。

現在、Node.js 上でサービスを構築していますが、これは、それぞれの開発者が別の言語を使用して近くに置くプラットフォームにすぎません。 しかし、私たちは座って、この試合にはろうそくを払う価値があると考えました。 つまり、これはあなたが座って考えるべき問題なのです。

サービスをどのように監視していますか? ログをどのように収集して監視しますか?

Elasticsearch でログを収集して Kibana に置きますが、本番環境かテスト環境かに応じて、そこで異なるコレクターが使用されます。 どこかの木こり、どこか他の何か、覚えていません。 また、特定のサービスでは、Telegraf をインストールし、別の場所で個別に撮影している場所がまだいくつかあります。

同じ環境で Puppet と Ansible を共存させるにはどうすればよいですか?

実際、現在 XNUMX つの環境があり、XNUMX つは Puppet、もう XNUMX つは Ansible です。 私たちはそれらのハイブリッド化に取り組んでいます。 Ansible は初期セットアップに適したフレームワークですが、Puppet はプラットフォーム上で直接実践的な作業が必要なため、初期セットアップには適していません。Puppet は構成の収束を保証します。 これは、プラットフォーム自体が最新の状態に維持されることを意味し、駆除されたマシンを最新の状態に維持するには、ある程度の頻度で常にプレイブックを実行する必要があります。 それが違いです。

互換性をどのように維持しますか? Ansible と Puppet の両方に構成がありますか?

これは私たちの大きな苦痛であり、私たちは手の互換性を維持し、今このすべてからどこかに進む方法を考えています。 Puppet はパッケージをロールアウトしてそこにいくつかのリンクを維持し、たとえば Ansible はコードをロールアウトしてそこで最新のアプリケーション構成を調整していることがわかりました。

プレゼンテーションは Ruby のさまざまなバージョンについてでした。 どのような解決策でしょうか？

私たちはある場所でこれに遭遇しました、そして私たちはそれを常に頭の中に留めておかなければなりません。 アプリケーションと互換性のない Ruby 上で動作する部分をオフにし、分離しておいただけです。

今年のカンファレンス DevOpsDays モスクワ 7月11日にテクノポリスで開催されます。 レポートの応募はXNUMX月XNUMX日まで受け付けている。 書きます 話したいことがあれば、私たちに話してください。

参加者登録は受付中ですので、ぜひご参加ください！

出所： habr.com