広告技術の分野でマイクロサービスのアプリケーションを作成した経験

2015年8月、新しいアドテックプロジェクトAtukoを開始しました。

これは、専門家に焦点を当てたモバイル広告管理システムです。





Atukoでは、メイン広告システムMail.ruであるmyTargetの 1つのトラフィックチャネルの管理に焦点を当て、Odnoklassniki、モバイルVK、およびその他のMail.ruリソースの広告を組み合わせ、Runetオーディエンスの90％以上をカバーしました。 そして当然、広告主にはキャンペーンを作成し、結果を分析し、それらを管理するためのツールが必要です。





これらのツールの作成とシステムのアーキテクチャにどのようにアプローチしたかを正確に伝えたいと思います。



これは私たちのチームの広告技術分野における最初のプロジェクトではありません。 2009年から広告管理システムを開発し、Yandex.Direct、Google Adwords、Google Analytics、VK、Target @ mail.ru、その他のチャネル向けのツールを作成しています。 それが関連していた時代さえ見つけ始めました:)









この間、広告プラットフォームの特性、API、広告主自身の異常なタスクに関連する多くの落とし穴や驚きに直面し、多くの経験を積むことができました！ 1つの記事ですべてのことを話す方法はないため、興味がある場合は、得られた知識を共有しようとする一連の記事を作成します。



この記事では、Atukoのアーキテクチャとインフラストラクチャに関する重要なことと、なぜそうしなかったのかを説明します。

過去の経験と重要な教訓

過去の経験から、とりわけ、次の重要な教訓を学びました。

• システムのすべてのノードで柔軟なスケーリングが必要です 。 分析、作成、表示など、システムのどの部分で負荷が増加するかを事前に予測することは不可能です。
  
  小さな例を挙げます。 コンテキスト広告（Yandex.DirectとGoogle AdWords）を管理する場合、最初はすべてうまくいきましたが、成長はスムーズでした。 ある時点で、真に大規模なクライアントが登場します-そして、彼のタスクを実装するには、900万個のキーワードを管理する必要があります。これは、他の顧客を合わせた数倍です。 システムの一部（Googleアナリティクスからのコンバージョンの取得など）は負荷の増加に冷静に対処しましたが、その他の部分（すべてのキーワードの統計情報の取得など）は強力な最適化を必要としました。 そして、最も不愉快なことは、このクライアントのボリュームがシステム全体の作業に影響を与えたことです-それに応じて、他のクライアントも。
  
  これは、システムの個々の部分の分離と柔軟性、および顧客を互いに分離する能力を教えてくれました。
• 特定のクライアントの機能を構成する必要があります。
  
  多くの場合、個々のクライアントには独自の要件があり、異なるクライアントのタスクを1つのユニバーサルソリューションに結合することは困難または不可能です。特定のクライアントの機能のカスタマイズはより効果的です。 同時に、もちろん、このカスタマイズは他のユーザーに影響を与えるべきではありません。
  
  したがって、個々のクライアントに対して高度な機能を実行すると同時に、クライアントごとにシステム全体の個別のコピーを作成しない機能が必要です。
• フレームワークおよびプログラミング言語への依存の最小化。
  
  たとえば、私たちが作成したプロジェクトの1つは、それが構築されているフレームワークよりも長く存在しています-フレームワークのサポートと開発は停止しています。 さらに、プロジェクト全体を1つのプログラミング言語にリンクすると効率が低下します。各タスクに最適な言語を使用する方法はなく、新しいプログラミング言語を使用する方法もありません。

では、Atukoアーキテクチャのこれらのポイントをどのように予測しようとしたかを説明します。



プロジェクトの一般的なスキームは次のように表すことができます。

マイクロサービス

まず、すべてをマイクロサービス上に構築することにしました。 各マイクロサービスはHTTP APIを提供し、任意のテクノロジースタックに実装できます。 HTTP APIは独自のバランサーでサービスの1つのコピーとクラスター全体の両方を隠すことができるため、これにより、他のユーザーに気付かれずに各サービスをスケーリングする機会が与えられます。



さらに、各マイクロサービスは十分にシンプルであるため、プロジェクト全体に完全に浸ることなく理解できるため、開発が簡素化され、極端な場合には、かなり短時間でサービスを最初から書き直すことができます。

したがって、使用するテクノロジーからも独立しています。マイクロサービスのフレームワークが古くなっていても、マイクロサービスを新しいテクノロジーに移行できます。 そしてもちろん、この問題がより適切に解決されることを理解していれば、別のプログラミング言語を使用できます。



マイクロサービスを使用するときに生じる一般的な質問の1つは、機能をマイクロサービスに分割する方法です。 私たち自身は、特定の機能ユニットを個別のマイクロサービスに割り当てることを決定しましたが、これは小さな部分に分割する意味がありません。

例を挙げましょう。Atukoには、特別に細工されたExcelファイルを読み込むことにより、広告サイトに多数の広告キャンペーンと広告を作成する機会があります。 インターフェースに加えて、このプロセスには3つのマイクロサービスが関係しています。

• Excelファイルを解析し、myTargetにロードするデータセットを作成する
• データプラットフォームが広告プラットフォームのルールに準拠しているかどうかを確認する
• myTargetにデータを送信する

同時に、最後の2つのサービス（データの正確性の確認とデータの広告プラットフォームへの送信）は、Atukoと連携する他のシナリオでも使用されます（たとえば、広告はExcelだけでなくブラウザでも作成できます）。 同時に、サービスはデータの取得元を気にしません。サービスを実行して結果を渡すだけです。



しかし、マイクロサービスへの分割により、新しい問題が発生します。 特に、1つのアクションに複数のサービスが関与し、責任のあるサービスを見つけることがより困難になるため、デバッグはより困難になります。



テストもわずかに変わり、統合テストの重要性が大幅に高まります。 「真空」サービスは機能する可能性がありますが、一緒になってすでに失敗しています。



開発中に、追加の要件も表示されます。 特に、サービスの結果が実際にさらに進んだことを確認する必要があります。 そして、もちろん、適切に構築されたモニタリングは非常に重要です。 ただし、これらのポイントはいずれも、少なくとも別の記事、または本全体のトピックです。

ディスパッチャー

マイクロサービスの数が非常に急速に増加することを認識して、サービス間の通信の潜在的な問題を発見しました。 サービスが相互に直接通信する場合、それらの相互作用の全体像を構成することは困難であり、これはサービスの将来の修正に関する問題につながります。 それらの接続を減らすために、残りとの通信を担当する中央のマイクロサービス、つまりディスパッチャを導入することにしました。



各マイクロサービスは、作業の結果とともにイベントをディスパッチャに送信し、ディスパッチャは、サブスクライブされたサービスにイベントを送信します。 したがって、各マイクロサービスは外部環境の知識を必要としません。 代わりに、彼はディスパッチャの特定のイベントをサブスクライブし、作業の結果に応じて同じディスパッチャにイベントを送信するだけで十分です。

単位

ディスパッチャーの導入は、もう1つのタスク、つまり特定のクライアント用にカスタマイズされた機能の作成も解決します。 これは、ユニットの導入により可能です。各ユニットは、ディスパッチャとそれに対応するマイクロサービスの組み合わせです。

顧客の1人が、独自のCRMシステムから、独自の処理を必要とする独自の形式で変換をダウンロードする必要がある場合を考えてください。

この問題は、異なるユーザーが異なるマイクロサービスによって「サービス」される場合に解決できます。 2つのユニットを起動します。各ユニットには独自のディスパッチャと独自のサービスセットがあります。 同時に、一方のユニットでは通常のスキームに従ってサービスが機能し、もう一方のユニットではCRMクライアントからの変換を処理するサービスに置き換えられます。



ただし、外部システムとの対話など、いくつかのことはさまざまなユニットで重複することはありません。 たとえば、Atukoの場合、myTarget APIの使用には制限があります。したがって、外部通信は、リクエストの頻度を制御する1つのマイクロサービスを経由します。



ところで、ユニット内では、個々のサービスの動作だけでなく、サービスの数も変更できます。たとえば、データの処理または検証に新しいステップを追加します。



追加のユニットを起動することにより、サーバー全体のスケーリングも簡素化され、メンテナンスが大幅に簡素化されます。システムの複数のコピーではなく、個々の要素のみが複製されます。





もちろん、このアプローチには独自のニュアンスがあります。 たとえば、ディスパッチャは、システムノード間のすべての通信を処理する非常に忙しいサービスになります。 また、すべてのイベントが同等というわけではないことをすぐに考慮する必要があります。異なるイベントを異なる優先度で処理する必要があります。さもないと、多くの重要でないイベントが即時の反応を必要とする他のイベントの処理を遅くする可能性があります。 たとえば、ユーザーがキャンペーンを停止するコマンドを送信した場合、このタスクはすぐに実行する必要がありますが、統計のバックグラウンド更新は待機する場合があります。

Docker

一般に、上記のアプローチにより、起こりうる問題に備えることができました。 しかし、開発プロセスだけでなく、運用プロセスとも関連する別のタスクが発生しました。 このすべての経済を管理する方法は？ 各マイクロサービスは、任意のフレームワークの任意のテクノロジーを使用して実装でき、さまざまなライブラリに独自の依存関係があります。 たとえば、現時点ではgolang、python、およびphpの両方にマイクロサービスがあります。



この問題を解決するために、 Dockerを使用します。 各マイクロサービスに基づいて、Dockerイメージ（イメージ）が作成されます。これに基づいて、無制限の数のサービスを既に起動できます。 ただし、異なるマシンに配置することもでき、これによりスケーリングも簡素化されます。

リバースプロキシ

すべての呼び出しはリバースプロキシを経由します。 これにより、サービスで別のコンテナを上げるときに、目的のエントリを目的のアップストリームに追加するだけで済み、リバースプロキシはトラフィック自体を配信します。



リバースプロキシとして、 nginxを使用していますが、他のオプションも引き続き検討しています。



さらに、デプロイメントにはBlue-Green Deploymentテクニックを使用します。これは、サービスが新機能と旧機能の両方で同時に機能できることを意味します。 この場合、リバースプロキシが再び役立ち、2つのバージョン間でトラフィックを適切な割合で分散し、最終的に新しいバージョンに切り替えて、完全に動作していることを確認する機会を提供します。

DNS

開発を開始したとき、Dockerのネットワーク機能は十分に開発されていませんでした。 同時に、マイクロサービスへの便利なアクセス、外部からのバックエンドのアクセス不能性、および各ユニットを独自のサブネットに配置することが必要でした。



したがって、内部DNSを上げることにより、この問題を独自に解決しました。 特定のサービスは、名前とユニット名で簡単にアクセスできるようになりました。 現時点では、引き続きDNSを使用していますが、途中で他のオプションを検討しており、その選択肢はますます増えています。



ちなみに、これはマイクロサービスアーキテクチャのもう1つのプラスです。生活を楽にし、新しい機能のリリースを高速化し、信頼性を高めることができる新しいツールを簡単に導入できます。 これにより、古いコードの問題もなくなります。古いサービスは、現在のバージョンに簡単に置き換えることができます。

おわりに

このアプローチを適用した結果についてお話したいと思います。



このようなアーキテクチャを使用して1年経っても、マイクロサービスを使用して選択したアプローチにはまだ満足しています。 私たちが直面した困難や以前にはなかった新しい問題にも関わらず、このアプローチは全体として成果を上げ、割り当てられたタスクを解決しました。



そしてもちろん、Dockerは私たちにとって生活をずっと楽にしてくれます-私たちにとっては、それは素晴らしいビルドおよび配信ツールです。 みんなに安全にお勧めできます。 また、マイクロサービスベースのアプローチとDockerを組み合わせると、開発、テスト、さらには運用において多くの利点が得られます。



マイクロサービスとDockerのトピックに関する記事、レポート、ビデオの数が急速に増加しているのを見て、私は正しい選択をしたときを理解しています。その時でさえ、新しい、未検証のアプローチのように見えました。 したがって、新しいプロジェクトを開始するか、古いプロジェクトを変更する場合は、マイクロサービス、Dockerの使用、およびユニットへの分割を検討することをお勧めします。



興味があれば、この間取得した知識を引き続き共有する準備ができています： golangのマイクロサービス、監視とテスト、 ReactJS + Fluxに基づくインターフェイスなどについて。