UberでのMySQLドッキング

Uberエンジニアによって開発されたスキーマレスストレージシステムは、当社の最も重要かつ最大のサービス（ メザニンなど ）で使用されています。 スキーマレスは、 MySQLクラスター上で実行されるスケーラブルでフォールトトレラントなデータウェアハウスです¹。 これらのクラスターが16個ある場合、それらの管理は簡単でした。 しかし、現時点では1,000を超えており、少なくとも4,000のデータベースサーバーが展開されています。 そのようなシステムを管理するには、まったく異なるクラスのツールが必要です。

Schemadockに含まれる多くのコンポーネントのうち、比較的小さいが非常に重要な部分はDockerです。 よりスケーラブルなソリューションへの移行は私たちにとって画期的な出来事であり、この記事ではDockerがこれを達成するのにどのように役立つかについて話しました。

最初は、すべてのクラスターを管理するために、さまざまなスクリプトであるPuppetを使用し、多くのことを手動で行いました。 しかし、Uberの成長が速くなり、Uberが大きくなればなるほど、このアプローチを使い続けるのが難しくなりました。 そのため、MySQLクラスターを管理するためのより便利なツールを探し始めました。 主な要件は次のとおりです。

• 1つのホスト上の複数のデータベースサーバーの動作。
• 完全自動化。
• すべてのデータセンターのすべてのクラスターを管理および監視するための単一のエントリポイント。

その結果、Schemadockと呼ばれるソリューションができました。 現在、MySQLサーバーは、構成ファイルを使用してクラスタートポロジを決定するターゲット状態によって制御されるDockerコンテナーで動作します。 たとえば、クラスター「A」には3つのサーバーがあり、そのうちのどれがマスターになる必要があることを示している場合があります。 適切なロールを個々のサーバーに適用することは、特別なエージェントプログラムによって実行されます。 単一のサービスがすべてのサーバーのターゲット状態を監視し、標準から逸脱した場合、状況を修正するために必要なアクションを実行します。

なぜDockerなのか？

コンテナを使用すると、異なるバージョンと構成を持つ異なるホストで複数のMySQLプロセスを簡単に実行できます。 また、同じマシン上に複数の小さなクラスターを配置できるため、最終的には同じクラスター数でより少ないホストを使用できます。 最後に、Puppetに依存しなくなり、同じホスト設定を使用します。

Docker自身に関しては、現在、当社のエンジニアはそれに基づいてすべてのステートレスサービスを作成しているため、このシステムをよく知っています。 彼女はもちろん完璧ではありませんが、現時点では私たちにとって最良の選択肢です。

Docker以外には何がありますか？

Dockerの代替手段は次のとおりです。完全仮想化、 LXCコンテナー 、および例えばPuppetを使用してMySQLプロセスを直接管理します。 Dockerは当時の既存のインフラストラクチャに最も適していたため、非常に長い間選択しませんでした。 ただし、以前にDockerを使用していなかった場合、MySQLのみへの実装はかなり大きなプロジェクトになる可能性があります。そのためには、イメージの作成と配布、Docker自体の監視と更新、ログの収集、ネットワークとの連携機能などをマスターする必要があります。

つまり、Dockerのデプロイには時間とリソースが必要です。 さらに、Dockerはテクノロジーと見なされるべきであり、Dockerからすべての問題の解決策を期待すべきではありません。 Uberでは、Dockerがコンポーネントの1つにすぎないMySQLデータベース管理システムの設計に慎重に取り組みました。 しかし、すべての企業がUberの規模に達しているわけではないため、Puppet、 Ansible、または同様のソフトウェアを使用したほうがよい場合があります。

スキーマレスの画像

基本的に、このイメージはPercona Serverのダウンロードとインストールのみを行い 、 mysqldも起動します。これは、MySQLを搭載した標準のDockerイメージとほぼ同じです。 ただし、ダウンロードとインストールの間にさらにいくつかの操作が実行されます。

• 接続されたボリュームにデータがない場合は、ブートが必要です。 ウィザードでは、mysql_install_dbを実行し、いくつかの標準ユーザーとテーブルも作成します。 レプリカ（Uberの用語でいうミニオン-およその転送）の場合、バックアップコピーまたはクラスター内の別のノードからデータの読み込みを開始します。
• Mysqldは、データのダウンロードが完了するとすぐに起動します。
• 何らかの理由でデータのコピーが終了しない場合、コンテナは停止します。

コンテナの役割は、環境変数を使用して設定されます。 データを取得するメカニズムに注意する価値があります。イメージ自体には、レプリケーショントポロジ、ステータスチェックなどを設定するためのロジックが含まれていません。このロジックはMySQL自体よりも頻繁に変更されるため、それらを分離することは非常に合理的です。

MySQLデータディレクトリはホストファイルシステムからマウントされます。つまり、Dockerによる記録のオーバーヘッドはありません。 MySQLの構成は引き続きイメージに書き込まれるため、イメージは不安定になります。 構成自体は編集できますが、コンテナを再利用しないため、これらの変更は有効になりません。 コンテナが何らかの理由で停止した場合、再び使用されることはありません。 コンテナーを削除し、同じパラメーターを使用して最新のイメージから新しいコンテナーを作成し（それ以降、ターゲットの状態が変更された場合は新しいパラメーターを使用して）、それを開始します。

このアプローチには、次の利点があります。

• 構成のドリフトを制御することがはるかに簡単になっています。 この問題は、Dockerイメージのバージョン番号に要約されており、注意深く監視しています。
• MySQLの更新がはるかに簡単になりました。 新しいイメージを作成し、コンテナを順番に停止します。
• 何かが壊れた場合、再起動するだけです。 問題のあるコンテナを削除し、何も修復しようとせずに新しいコンテナを開始します。

イメージを作成するには、ステートレスサービスを提供する同じインフラストラクチャが使用されます。 また、データセンター間でイメージを複製して、ローカルレジストリで使用できるようにします。

同じホストで複数のコンテナを実行することには欠点があります。 コンテナ間には通常のI / O分離がないため、いずれのコンテナもI / Oシステムのスループット全体を使用でき、残りのコンテナの動作に悪影響を及ぼします。 I / OクォータはDocker 1.10に登場しましたが、まだ実験する時間がありませんでした。 ホスト上のコンテナの数を制御し、各データベースのパフォーマンスを常に監視することにより、この問題に取り組んでいます。

コンテナーとトポロジーの構成

ウィザードまたはレプリカとして構成できるDockerイメージができたので、何かがコンテナーを起動し、必要なレプリケーショントポロジを構成する必要があります。 これを行うために、すべてのデータベースの最終状態に関する情報を受け取る特別なエージェントが各ホストで起動されます。 最終状態の一般的な説明は次のとおりです。

“schemadock01-mezzanine-mezzanine-us1-cluster8-db4”: { “app_id”: “mezzanine-mezzanine-us1-cluster8-db4”, “state”: “started”, “data”: { “semi_sync_repl_enabled”: false, “name”: “mezzanine-us1-cluster8-db4”, “master_host”: “schemadock30”, “master_port”: 7335, “disabled”: false, “role”: “minion”, “port”: 7335, “size”: “all” } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mezzanineデータベース（ポート7335）のレプリカの1つがホストschemadock01で実行され、schemadock30：7335のデータベースがそのマスターになる必要があると書かれています。 サイズはすべてに設定されます。 つまり、このデータベースはschemadock01上の唯一のデータベースであり、使用可能なすべてのメモリを使用する必要があります。

このようなターゲット状態の説明を作成する手順は、別のパブリケーションのトピックです。次のステップに進みます。ホストで実行されているエージェントは、ターゲット状態の説明を受信して​​ローカルに保存し、処理を開始します。

処理は30秒ごとに実行される無限ループです（30分ごとに1回Puppetを実行するようなものです）。 ループでは、現在の状態とターゲットの状態の対応がチェックされます。 これを行うには、次のアクションが実行されます。

1. コンテナが実行されているかどうかを確認してください。 そうでない場合は、作成して実行します。
2. コンテナ複製トポロジを確認してください。 彼女に何か問題がある場合は、修正してみてください。
   
   
   • これがレプリカであるがマスターである必要がある場合は、ロールの変更が安全であることを確認してください。 これを行うには、現在のマスターの読み取り専用ステータスが設定されているかどうか、およびすべてのGTIDが受信および適用されているかどうかを確認します。 すべての条件が満たされている場合、前のウィザードのリンクを解除して記録を有効にすることができます。
   • これが無効にすべきウィザードである場合、読み取り専用モードを有効にします。
   • これがレプリカであるが、レプリケーションが実行されていない場合は、レプリケーションを構成します。
3. データベースの役割に応じて、さまざまなMySQLパラメーター（read_onlyおよびsuper_read_only、sync_binlogなど）を確認します。 ウィザードで書き込みを有効にする必要があり、レプリカはread_onlyなどにする必要があります。さらに、binlog fsyncおよび同様のパラメーター²を無効にすることで、レプリカの負担を軽減します。
4. pt-heartbeatやpt-deadlock-loggerなど、すべての補助コンテナーを開始または停止します。

私たちは「1つのプロセス-1つの目標-1つのコンテナ」というアイデアを堅実に支持していることに注意することが重要です。 この場合、作業コンテナを再構成する必要はありません。さらに、更新が大幅に簡素化されます。

エラーが発生した場合、プロセスは対応するメッセージを生成して終了し、次の試行中に手順全体が再び繰り返されます。 エージェント間の調整の必要性を最小限に抑えるような方法でシステムを構成しようとします。 これは、たとえば、新しいクラスターを初期化するときにシーケンスを気にしないことを意味します。 この操作を手動で行う場合、およそ次の手順を実行する必要があります。

• MySQLウィザードを作成し、動作準備が整うまで待ちます。
• 最初のレプリカを作成してマスターに接続し、
• 残りのレプリカについて前の段落を繰り返します。

その結果、同様のことが依然として起こります。 しかし同時に、ステップの順序についてはまったく心配していません。 必要な構成を記述するターゲット状態のみを作成します。

 “schemadock01-mezzanine-cluster1-db1”: { “data”: { “disabled”: false, “role”: “master”, “port”: 7335, “size”: “all” } }, “schemadock02-mezzanine-cluster1-db2”: { “data”: { “master_host”: “schemadock01”, “master_port”: 7335, “disabled”: false, “role”: “minion”, “port”: 7335, “size”: “all” } }, “schemadock03-mezzanine-cluster1-db3”: { “data”: { “master_host”: “schemadock01”, “master_port”: 7335, “disabled”: false, “role”: “minion”, “port”: 7335, “size”: “all” } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この情報は適切なエージェントにランダムな順序で送信され、タスクの完了を開始します。 ターゲット状態を達成するには、シーケンスによっては、いくつかの試行が必要になる場合があります。 通常は少数ですが、一部の操作は数百回再起動されます。 たとえば、レプリカが最初に起動された場合、レプリカはマスターに接続できず、操作が開始されるまで何度もこれを試行する必要があります（長時間かかる場合があります）。

マスターの前に2つのレプリカが開始された例。 手順1および2では、ウィザードからスナップショットを取得できないため、起動プロセスは失敗します。 ウィザードが最終的に開始されると（ステップ3）、レプリカはデータに接続して同期できるようになります（ステップ4および5）。

Docker環境で作業する

ほとんどのホストには、 LVMに devicemapperを使用してDocker 1.9.1がインストールされています。 デバイスマッパーにLVMを使用することは、ループバックよりも生産的なソリューションであることが証明されました。 Devicemapperには多くのパフォーマンスと信頼性の問題がありますが、 AuFSやOverlayFSのような代替手段も理想からは程遠い³です。 長い間、コミュニティはストレージ組織のどのバリエーションが優れているかを判断できませんでした。 しかし最近、OverlayFSを支持する声が増えており、これも安定しているようです。このファイルシステムに切り替えて、同時にDocker 1.12.1にアップグレードする予定です。

Dockerの不便な点の1つは、サービスの再起動時にコンテナを再起動する必要があることです。 これは、ホストのアップグレード中に機能するウィザードがないため、アップグレードプロセスを制御する必要があることを意味します。 幸いなことに、Docker 1.12では、コンテナを再起動せずにデーモンを再起動および更新するオプションが追加されたため、この問題が最後に発生することを願っています。

Dockerの次の各バージョンには、多くの改善と新機能に加えて、かなりの数のバグがあります。 1.12.1は以前のものよりも優れているように見えますが、それでも特定の問題が発生します。

• Dockerが数日間停止せずに動作した後に、Docker検査がハングすることがあります。
• ユーザーランドプロキシでブリッジネットワーキングを使用すると、TCP接続を終了するときに奇妙な動作が発生します。 クライアント接続は、RST信号を受信せず、タイムアウトの設定に関係なく開いたままになることがあります。
• コンテナプロセスは時々pid 1（init）に再割り当てされ、Dockerはそれらを失います。
• Dockerデーモンが非常に長い時間新しいコンテナを作成する場合が定期的にあります。

おわりに

まず、Uberストレージクラスター管理システムの要件のリストを定義することから始めました。

1）1つのホスト上の複数のコンテナ、

2）自動化、

3）単一のエントリポイント。

単一のユーザーインターフェイスとシンプルなツールを使用して毎日のメンテナンスを実行できるようになりました。いずれもホストに直接アクセスする必要はありません。

管理コンソールのスクリーンショット。 ここでは、ターゲット状態を達成するプロセスを見ることができます。この場合、クラスターを2つの部分に分割し、最初に2番目のクラスターを追加してから、レプリケーション接続を切断します。

同じホストで複数のコンテナが起動されるため、コンピューティングリソースをより完全に使用します。 車両全体の制御された更新を実行することが可能になりました。 Dockerを使用すると、すぐにこれを達成できました。 Dockerでは、テスト環境でクラスター全体のインストールを開始することもできます。これを使用して、さまざまな操作手順をテストできます。

2016年の初めにDockerへの移行を開始し、現在では約1,500のDocker運用サーバー（MySQLのみ）が実行され、約2,300のMySQLデータベースが展開されています。

Schemadockには他にも多くのコンポーネントがありますが、Dockerが本当に役に立ちました。 彼と一緒に、私たちは迅速に前進する機会を得ました。既存のUberインフラストラクチャと密接に関連して多くの実験を行いました。 1日あたり数百万のエントリを追加する旅行リポジトリは、（他の情報のリポジトリとともに）ドッキングされたMySQLデータベースに基づいています。 言い換えれば、Dockerがなければ、Uberユーザーは文字通り遠くまで行かないでしょう。

Joakim Rechtは、Uber Engineeringのオーフスオフィスに常勤するソフトウェアスペシャリスト（エンジニア）であり、インフラストラクチャオートメーションSchemalessの技術エキスパートでもあります。

---

¹正確には、Percona Server 5.6

²sync_binlog = 0およびinnodb_flush_log_at_trx_commit = 2

³問題の小さなコレクション： https : //github.com/docker/docker/issues/16653、https : //github.com/docker/docker/issues/15629、https : //developerblog.redhat.com/2014/09 / 30 / overview-storage-scalability-docker /、https：//github.com/docker/docker/issues/12738