複雑なマイクロサービスの世界でのイベント、バス、データ統合

Valentin Gogichashviliがマイクロサービスについて説明します。 Highload ++を使用したレポートのトランスクリプトを次に示します 。



こんにちは、バレンティン・ゴギチャシビリです。 私はすべてのスライドをラテン語で作成しました。問題がないことを願っています。 私はザランド出身です。



ザランドとは何ですか？ あなたはおそらくラモダを知っています、ザランドは彼の時代のラモダのお父さんでした。 Zalandoが何であるかを理解するには、Lamodaを導入し、数回増やす必要があります。



Zalandoは衣料品店です、私たちは靴を販売し始めました、ところで非常に良いです。 ますます拡大し始めました。 外では、サイトは非常にシンプルに見えます。 Zalandoで6年間働いており、8年間存在していたこの会社は、ヨーロッパで最も急速に成長した会社の1つでした。 6年前、私がZalandoに来たとき、それはおよそ100％成長しました。



私が6年前に始めたとき、それは小さなスタートアップでした、私はかなり遅く到着しました、すでにそこに40人がいました。 私たちはベルリンでスタートし、6年以上にわたり、Zalando Technologyをヘルシンキやダブリンを含む多くの都市に拡大してきました。 データサイエンスはダブリンにあり、モバイル開発者はヘルシンキにいます。



Zalando Technologyは成長しています。 現時点では、月に約50人を雇用していますが、これはひどいことです。 なんで？ 世界で最もクールなファッションプラットフォームを構築したいからです。 非常に野心的な、何が起こるか見てみましょう。



少し歴史に戻って、あなたがキャリアのある時点であった可能性が最も高い古い世界を紹介したいと思います。



Zalandoは、Webアプリケーション、バックエンド、データベースの3つのレベルを持つ小さなサービスとして始まりました。 Magentoを使用しました。 私がZalandoに電話されたとき、私たちは世界最大のMagentoユーザーでした。 MySQLには大きな頭痛の種がありました。



REBOOTプロジェクトを開始しました。 私はこのプロジェクトに6年前に来ました。

私たちは何をしましたか？

Javaを知っていたので、Javaですべてを書き直しました。 PostgreSQLを知っていたので、どこにでもPostgreSQLをインストールしました。 Pythonは技術的な問題です。 ほとんどすべての普通の人が、ツール用のPythonが唯一の正しい解決策であると私を支持します（Perlの世界の人々、私を殺さないでください）。 Pythonは、ツールを書くための良いジョークです。



このようなスキームの開発を開始しました。







マクロサービスシステムがありました。 Javaバックエンド、PostgreSQLシャーディングを使用したPostgreSQLストレージ。 2年前、同じ会議で、PostgreSQLシャーディングの方法、回路の管理方法、ダウンタイムなしでのバージョンの展開方法について話しましたが、非常に面白かったです。



私が言ったように、Javaは皆知っていました。 SOAPは、マクロサービスを相互に結合するために使用されました。 PostgreSQLは、非常にクリーンなデータを持つ機会を与えてくれました。 スキーマ、クリーンデータ、トランザクション、ストアドプロシージャがあり、すべてのJava開発者や、PHPの世界から残った人々にJavaとストアドプロシージャを教えました。



1つのヒント：1か月あたり1,500万人未満のユーザーモードの場合、Java SProc Wrapperシステムを使用して、JavaからPostgreSQLを自動的にシャードできます。 PostgreSQLがRSPシステムに組み込まれていることは、本質的に非常に興味深いことです。



すべてが順調で、すべてを書き直しました。 最初に倉庫の管理システムを購入してから、すべてを書き直しました。 システムを購入した人がこれを行うよりもはるかに速く移動しなければならなかったからです。



スタッフとの問題が始まるまで、すべてが完璧に機能しました。 私たちの美しい世界は目の前で崩れ始めました。 Javaレベルで導入した標準化システム、そのレベル、SOAPは崩れ始めました。 人々は不平を言い始め、去るか、または来ない。



私たちは彼らに言いました：あなたがJavaで書かなければならない、あなたが去るならば、我々は何をしますか？ HaskellまたはClojureに何かを書いて出て行ったら、どうしますか？ そして、彼らは私たちにあなたをファックと答えた。



私たちはこの問題を真剣に考えることにしました。 アーキテクチャだけでなく、組織全体を再構築することにしました。 ドイツの業界には見られなかった組織の再構築プロセスを開始しました。私たちは、持っていたものをすべて完全に破壊すると言いました。 それは約900人の人がいた組織でした、私たちはそれがあった形で階層構造を破壊しています。 Radical Agilityを発表します。

これはどういう意味ですか？

自律的で有意義に前進するチームがあることを発表します。 もちろん、私たちはビジネスに従事していた人々が欲しいのです。彼らはスキルを持ってこのビジネスをしました。



自律チーム。



独自の技術スタックを選択できます。 チームがHaskellまたはClojureで書くことを決定した場合、それもそうです。 しかし、あなたはそれを支払う必要があります。 チームは自分で書いたサービスをサポートし、夜間に目を覚ます必要があります。 永続スタックの選択を含む。 MongoDBを選択する場合は、PostgreSQLを教えましたが、停止することはありません。MongoDBはロックされています。 テクノロジーレーダーを使用して、危険と見なされ、赤のセクターに置かれている月次調査とテクノロジーを実施しています。 これは、チームがこれらのテクノロジーを選択できることを意味しますが、何か問題が発生した場合は完全に責任を負います。



チームはAWSアカウントによって分離されると述べました。 それ以前は、AWSを選択して独自のデータセンターにいましたが、悪魔と取引をしました。 私たちは言った、それはもっと費用がかかることは知っているが、もっと速く動くだろう。 独自のデータセンターでは、以前のような状況は発生しません。1台のハードドライブを注文するのに6週間かかりました。 それは耐えられず、不可能でした。 前進できませんでした。



自治は無秩序であると信じる人が多すぎます。 自律は無秩序ではありません。 自律性には、特に上場企業であるZalandoにとって多くの責任が伴います。 私たちは証券取引所にいます。公開会社と同様に、監査人が私たちのところに来て、私たちのシステムの仕組みをチェックします。 開発者がAWSで作業できるようにする何らかの構造を作成する必要がありましたが、それでもレベルの監査人の質問に答えることができました。



結果はそのようなシステムです：







できるだけシンプルにしたかったのですが、本当にシンプルです。 しかし、誰もが彼女を見ると誓います。



このスピードとオープンさで、リマインダーであるAWSにアクセスする場合、およびマイクロサービスまたは公共サービスでアイデアを選択する場合、料金を支払う必要があります。 安全なシステムを作りたい場合など、監査人が尋ねることができる質問に答えます。



もちろん、さまざまなテクノロジースタックをサポートするために、JavaとPostgreSQLの標準化レベルをより高いレベルに引き上げると述べました。 標準化レベルをREST APIのレベルに引き上げています。



これはどういう意味ですか？ これは以前のレポートで、API記述システムが必要であると書きました。 マイクロサービスが相互に通信する方法の説明。 注文が必要です。 あるレベルでは、標準化する必要があります。 APIの最初のシステムがあると発表しました。 そして、各サービスは作成を開始する前に、ギルドAPIにアクセスし、承認されたAPIの一部としてAPIを受け入れるように説得する必要があります。 非常に興味深いREST APIガイドラインを作成しました。 一部のリソースでも参照されていました。 サーバーのルートとしてSwagger（OpenAPI）を使用できるようにするAPI最初のライブラリ。 たとえば、接続はPythonのフラスコのルートであり、play-swaggerはScalaのプレイシステムのルートです。 Clojureには同じルートがあり、非常に便利です。 Swaggerファイルを最初に記述し、マイクロサービスから何を達成したいのかを記述してから、システム上のどの関数がAPIで特定の操作を実行するかを単に指定します。



しかし、問題はマイクロサービスにあります。 このフレーズを数回繰り返したいです。 マイクロサービスは組織の問題への対応であり、これは技術的な答えではありません。 小さい人にはマイクロサービスを勧めません。 Scalaで1つのサービスを作成し、PythonまたはHaskellで別のサービスを作成する必要がない、多様な技術基盤に問題がない人にはマイクロサービスを勧めません。 マイクロサービスに関する問題の数は非常に多いです。 この障壁。 それを克服するためには、私たちがやったように、この前に多くの痛みを経験する必要があります。



ワールドサービスの最大の問題の1つ：定義によるマイクロサービスは、データ永続性システムへのアクセスをブロックします。 ベースはマイクロサービス内に隠されています。



したがって、従来の抽出変換ロードプロセスは機能しません。



一歩戻って、クラシックの世界で私たちがどのように働いているかを思い出しましょう。 何がありますか？ 私たちには古典的な世界があり、開発者、ジュニア開発者、シニア開発者、DBA、ビジネスインテリジェンスがいます。

どのように機能しますか？

単純なケースでは、ビジネスロジック、データベースがあり、ETLプロセスはデータベースから直接データを取得し、Date Warehouse（DWH）にプッシュします。



大規模には、多くのサービス、多くのデータベース、1つのプロセスがあり、これらはほとんどペンで書かれています。 データはこれらのデータベースから取得され、ビジネスアナリスト向けの特別なデータベースに格納されます。 それは非常によく構成されており、ビジネスアナリストは彼らが何をしているかを理解しています。



もちろんそれだけです-問題がないわけではありません。 自動化することはすべて非常に困難です。 マイクロサービスの世界では、すべてが私たちとは異なります。



マイクロサービスを発表したとき、Radical Agilityを発表したとき、開発者向けにこれらすべての素晴らしいイノベーションを発表したとき、ビジネスアナリストは非常に不満でした。



膨大な数のマイクロサービスからデータを収集する方法は？



これは数十個ではなく、数百個または数千個です。 それから、バレンタインは馬に乗って言います：私たちはすべてをストリームに、キューに書きます。 それから建築家は言う：なぜキュー？ 誰かがKafkaを使用し、誰かがRabbitを使用します。これらすべてをどのように統合しますか？ 私たちの警備員は言った：決して人生では、私たちは許可しません。 私たちのビジネスアナリストは、図がない場合、私たちはハングアップし、何が起こっているのか理解できない、それは単なるデータ転送システムではなく溝であると言いました。



私たちは座って何をすべきかを協議し、決定し始めました。 私たちの主な目標：システムの使いやすさ、単一障害点がないこと、それが落ちた場合にすべてが落ちるようなモンスターがないことを望みます。 安全なシステムが必要であり、このシステムはビジネスインテリジェンスのニーズを満たす必要があり、システムはデータサイエンスを満たす必要があります。 良い場合には、バスを流れるこのデータを他のサービスが使用できるようにする必要があります。



とても簡単です。 イベントバス。



イベントインテリジェンスをイベントバスから、またはデータ量の多いサービスに取り込むことができます。 DDDMは最近、お気に入りのコンセプトになっています。 これは、データ駆動型の意思決定システムです。 どんなマネージャーもそのような言葉に喜んでいるでしょう。 機械学習とDDDM。

何を思いつきましたか？

ナカディ。 あなたはおそらく私の姓がかなりグルジア人であることを理解したでしょう。 グルジア語のナカディは流れを意味します。 たとえば、渓流。



私たちはそのようなストリームを作り始めました。 私たちがそこに置いた基本原則は、少し繰り返します。



標準のHTTP APIを用意すると述べました。 可能であれば-安らかな。 集中型またはおそらく集中型ではないイベントタイプレジストリを作成します。 さまざまなクラスのイベントタイプを紹介します。 たとえば、現時点では2つのクラスがサポートされています。 これらは、データキャプチャとビジネスイベントです。 つまり、エンティティが変更された場合、必要なすべてのメタ情報とともにイベントキャプチャを記録できます。 ビジネスプロセスで何かが発生したという情報がある場合、これは通常、はるかに単純なケースであり、より単純なイベントを記述できます。 それでも、ビジネスアナリストは、自動的に解析できる組織化された構造を持つことを求めています。



PostgreSQLとスキーマの豊富な経験により、バージョン管理スキーマのサポートなしでは何も機能しないことがわかっています。 つまり、プログラマが作成された順序を記述し、次に作成された順序を記述する必要があるレベルまでスライドダウンすると、基本的にMicrosoft Windowsに似たシステムを作成し、特に理解するために非常に困難になりますエンティティの開発方法、エンティティのバージョン管理方法。 メッセージの到着にできるだけ早く応答し、メッセージの到着を希望するすべての人に通知できるように、このインターフェイスでデータをストリーミングできることが非常に重要です。



車輪を再発明したくありませんでした。 私たちの目標は、既存のシステムを使用する最小のシステムを作成することです。 したがって、現時点では、Kafkをアンダーラインシステムとして、PostgreSQLをメタデータとスキーマを保存するために使用しています。



Nakadi Clusterは私たちが持っているものです。 オープンソースプロジェクトの形で存在します。 現時点では、彼は以前に登録されたスキームを検証しています。 彼は、イベントのメタフィールドに追加情報を記録できます。 たとえば、到着時刻、またはクライアントがイベントの一意のIDを作成しなかった場合、一意のIDをそこにプッシュできます。



また、オフセットを制御する必要があると感じました。 カフカの仕組みを知っている人。 誰もが知っていますか 良いが、ほとんどではない。 Kafkaは、プロデューサーがデータを順番に書き込む古典的なpub /サブシステムですが、クラシカルメッセージシステムのように、クライアントはデータを保存しません。



クライアント用にメッセージの個別のコピーは作成されません。クライアントが必要とするのはオフセットのみです。 つまり、この無限のストリームのシフトです。 Kafkaは、各行に番号が付けられたデータの無限のストリームであると想像できます。 クライアントがデータを収集する場合、ポジションXから読み取ります。カフカはポジションXからこのデータを提供します。これにより、データの順序付けが保証され、通常のメッセージで通常行われるように、多くの情報がサーバーに保存されなくなります読み取りイベントの一部をコミットできるシステム。 この状況では、読み取りブロックの一部をコミットすることができないという問題があります。 オフテキストが開始されました。Kafk'yについて話したくありませんでした。



高レベルのインターフェースにより、クライアントはkafkからの読み取りが非常に簡単になります。 クライアントは、読み込むセクション、保存するオフセットに関する情報を交換しないでください。 クライアントは単にシステムから必要なものを受け取ります。 抵抗が最小になる経路を決定しました。 ZookeeperはKafkにすでに存在します。Zookeeperがどれほどひどいものであっても、すでに所有しているので、管理する必要があり、オフと追加情報を保存するために使用します。 PostgreSQL-メタデータおよびスキーマストレージ用。



今、私たちがどの方向に進んでいるのかをお話ししたいと思います。



私たちはとても速く動いています。 したがって、ベルリンに戻ると、いくつかの部品がすでに作られています。



現時点では、Nakadi Clusterがあり、Nakadi UIがあります。NakadiUIは、他の人の興味を引くためにElmで書き始めました。 エルムはクールだ、彼を愛している。



次のステップでは、複数のクラスターを管理できるようにします。 新しいプロデューサーが到着し、何も警告せずに毎秒1万件のイベントを書き始めたときに、すでに妨害を確認しました。



クラスターには、拡張する時間がありません。 データの種類ごとに異なるクラスターが必要です。 Kafk'yへの接続がないように、インターフェイスの標準化を具体的に行いました。



Kafk'iからRedisに切り替えることができます。 そして、RedisからKinesisまで。 基本的に、アイデアは、サービスの必要性とそれらが書き込むイベントのプロパティに応じて、誰かが順序や順序に興味がない場合、順序をサポートせず、Kafkaよりも効率的なシステムを使用できるということです。 現時点では、インターフェイスを使用してこれを抽象化する機会があります。



Nakadi Scheme Managerは、ベイクする必要があるため、クラスターから引き出す必要があります。 次のステップは、回路が検出されるようなアイデアです。 つまり、マイクロサービスが上昇し、そのswaggerファイルを発行し、イベントのリストをswaggerと同じ形式で発行します。 自動的に、クローラーはそれをすべて取り除き、開発者がそれを展開する前に回路をメッセージバスに追加で挿入する必要性を排除します。



そしてもちろん、トポロジー・マネージャー。これにより、何らかの方法でプロデューサーとコンシューマーを異なるクラスターにルートできます。 彼らはカフカが象のように働くと言った。 いいえ、象のようではなく、蒸気機関車のようです。 私たちの状況では、このエンジンは常に壊れています。 このエンジンを誰が作ったのかわかりませんが、AWSでKafkを管理するために、それほど簡単ではないことがわかりました。



私たちは非常に良い名前で非常にロシア語のブブクシステムを書きました。



ぶぶくは何をしますか？



ブブクが何をしていたかを示す大きなスライドがありましたが、非常に大きいことがわかりました。 ここですべてを見ることができます 。



予告編では、ブブクは他の人がカフクでやらないことをするという目標を持っています。 主なアイデアは、自動的に報告、自動スケーリング、落雷、インスタンスを殺す狂った猿を生き残る能力です。



ちなみに、Chaos Monkeyはシステムをテストしており、すべてうまく機能しています。 マイクロサービスを作成する場合は、このシステムがChaos Monkeyをどのように生き残るかを常に考えてください。 これは、ノードをランダムに削除したり、ネットワークを切断したり、システムを台無しにするNetflixシステムです。



構築するシステムが何であれ、それをテストしないと、何かが壊れても機能しません。



表面的な話を締めくくりたいと思います。私が話したことは、私たちは現在オープンソースで開発しています。 なぜオープンソースなのですか？ Zalandoがなぜオープンソースをするのかを書いた。



人々がオープンソースで書くとき、彼らは会社のためではなく、自分自身のために部分的に書く。 したがって、製品の品質が向上し、インフラストラクチャからの製品の分離が向上することがわかります。 zalando.de内で書き込みを行ったり、キーを編集したり、Gitでコミットしたりする人はいません。



ソースをオープンする方法に関する原則があります。 ソースをオープンすべきかどうか、会社に質問はありますか？ オープンソースの第一原則があります。 プロジェクトを開始する前に、オープンソースの価値があるかどうかを考えます。 この質問を理解して回答するには、質問に回答する必要があります。

• 誰がこれを必要としますか？
• これが必要ですか？
• これをオープンソースプロジェクトとしてやりたいですか？
• この公開ツリーに保存したものを保存できますか？

オープンソースを必要としない場合があります：

• プロジェクトにドメインの知識が含まれている場合、会社を会社にするのはもちろん、オープンソースにすることはできません。

これが最後のスライドです。今日言及されたプロジェクトは次のとおりです。







zalando.github.ioにアクセスすると、膨大な数のPostgreSQLプロジェクトがあり、バックエンドとフロントエンドの両方に多くのライブラリがあるため、お勧めします。



時間切れです。





レポート：マイクロサービスの困難な世界におけるイベント、バス、およびデータ統合