人なしでTarantoolを展開する

開発者が自分の問題の解決策をすばやく投入し、それを本番環境に確実に提供できるようにするにはどうすればよいですか？アプリケーションのデプロイは簡単です。本格的な製品にして、12のチームが100のインスタンスで使用できるようにすることはより困難です。そして、数テラバイトのマスターシステムについて話していると、不安のレベルが上がり、手が汗をかき、ベースが継ぎ目で破裂します（多分）。



ダウンタイムやサービス拒否なしで展開する方法を共有したいと思います。 Jenkinsパイプライン、仲介者なし、60分で本番環境に500インスタンス。これはすべてオープンソースです。詳しくは猫の下でお誘いします。



私の名前はRomanProskinです。Mail.ruGroupでTarantoolをベースにした高負荷システムを作成してサポートしています。私たちのチームがTarantoolアプリケーションのデプロイメントをどのように構築したかを説明します。これにより、ダウンタイムやサービス拒否なしに本番環境でコードが更新されます。その過程で遭遇した問題と、最終的にどのような解決策を選んだかについて説明します。私たちの経験がデプロイメントの構築に役立つこと を願っ ています。



アプリケーションのデプロイは簡単です。 TarantoolにはカートリッジCLI ユーティリティ（ github）。これにより、クラスター化されたアプリケーションは数分でDockerのどこかにデプロイされます。ソリューションをひざまずいて本格的な製品に変えることははるかに困難です。何百ものインスタンスを簡単に処理できるはずです。同時に、トレーニングのレベルが異なる数十のチームで需要がある必要があります。



展開の背後にある考え方は非常に単純です。

1. あなたは2つの鉄のサーバーを取ります。
2. それぞれで1つのインスタンスを起動します。
3. それらを1セットのレプリカに結合します。
4. 1つずつ更新します。

しかし、数テラバイトのデータを含むマスターシステムになると、不安のレベルが上がり、手が汗をかき、ベースが継ぎ目で破裂します（多分）。

初期条件の設定

システムには厳格なSLAがあります。計画された作業を考慮して、99％の可用性を確保する必要があります。これは、問い合わせに応答しない余裕がある年間合計87時間があることを意味し ます。 87時間というのは大変そうです が…



プロジェクトは約1.8TBのデータ量を想定して設計されています。再起動だけで40分かかります！変更が手動で行われる場合、更新自体は上からさらに追加されます。私たちは週に3回の更新を行う：40 * 3 * 60分の52 =合計 104時間を- SLAに違反しています。そして、これらは確実に発生する事故を考慮せずに計画された作業にすぎ ません。



このアプリケーションは、高いユーザー負荷のために開発されました。つまり、安定性の要件を満たす必要がありました。ノードに障害が発生した場合にデータが失われないようにするために、クラスターを地理的に2つのデータセンターに分割することにしました。そこで、SLAに違反しない展開メカニズムを決定しました。インスタンスをすぐに更新するのではなく、データセンター全体でバッチで更新します。



負荷を2番目のデータセンターに転送すると、更新全体を通じてクラスターを記録できるようになります。これは古典的なショルダー展開であり、標準的なディザスタリカバリプラクティスの1つです 。



データセンター間で更新する機能は、ダウンタイムゼロの展開の重要な要素の1つです。このプロセスについては、記事の最後で詳しく説明しますが、ここでは、非人道的な展開の特徴と発生した問題について詳しく説明します。

問題

道路を横切ってトラフィックを転送します

いくつかのデータセンターがあり、リクエストはそれらのいずれかに送信できます。データを取得するために近くのデータセンターにアクセスすると、応答時間が1〜100ミリ秒長くなります。クロストラフィックを回避するために、データセンターにアクティブタグと スタンバイタグを付けました 。バランサー（nginx）は、トラフィックが常にアクティブなデータセンターに流れるように構成されています。 Tarantoolがクラッシュするか、アクティブなデータセンターで使用できなくなった場合、Tarantoolは自動的に予約に切り替わります。



すべてのユーザー要求は重要であるため、接続が維持されるようにする方法が必要です。このために、データセンター間でトラフィックを切り替える別のansibleプレイブックを作成しました。切り替えはbackup



、説明のディレクティブを使用して実装され ます upstream



サーバー用。アップストリームは制限によって選択され、制限によってアクティブになります。残りは規定されてい backup



ます：nginxは、アクティブなものがすべて利用できない場合にのみ、それらのトラフィックを許可します 。構成を変更する場合、開いている接続は閉じられず、 新しい要求は再起動の対象とならないルーターに送信されます。



インフラストラクチャに外部ロードバランサーがない場合はどうすればよいですか？ Tarantoolインスタンスの可用性を監視する独自のミニバランサーをJavaで作成します。ただし、この個別のサブシステムには、独自の展開も必要です。もう1つのオプションは、ルーター内にスイッチングメカニズムを構築することです。 1つ変更はありません。HTTPトラフィックを制御する必要があります。



nginxで整理しましたが、問題はそれだけではありませんでした。レプリカセット内のマスターに対しても切り替えを行う必要があります。前述したように、不要なネットワークトリップを回避するために、データはルーターの近くに保持する 必要があります。さらに、現在のマスター（つまり、書き込みアクセス権を持つストレージインスタンス）がクラッシュした場合、フェイルオーバーメカニズムはすぐには機能しません。クラスターはインスタンスが使用できないことについて一般的な決定を下しますが、影響を受けるデータに対するすべての要求はエラーになります。この問題を解決するには、クラスターAPIに対してGraphQLクエリを使用するプレイブックをコンパイルする必要もありました。



ウィザードを変更し、ユーザートラフィックを切り替えるメカニズムは、ダウンタイムのない展開の最後の重要な要素です。制御されたロードバランサーは、接続の喪失やユーザーリクエストの処理におけるエラー、およびマスターの変更（データアクセスのエラー）を回避します。これらの3つの柱の肩の更新とともに、フォールトトレラントな展開が得られ、さらに自動化されました。

レガシーとの戦い

お客様はすでに既成のロールアウトメカニズムを持っていました。インスタンスを段階的に展開および構成するロールです。次に、魔法の ansible-cartridge（ github）それはすべての問題を解決します。ansible-cartridge自体がモノリスであることだけを考慮していませんでした。1つの大きな役割であり、そのさまざまな段階がラベルと個別のタスクで区切られています。これを最大限に活用するには、アーティファクトの配信プロセスの変更、ターゲットマシンのディレクトリ構造の変更、オーケストレーターの変更などが必要でした。私は、ansible-cartridgeを使用してデプロイメントを改良するのに1か月を費やしました。モノリシックな役割は、完成したプレイブックに適合しませんでした。この形ではうまくいきませんでした、そして私は同僚からのただの質問に止められました：「私たちはそれが必要ですか？」



私たちはあきらめませんでした-クラスター構成を単一の部分から分離しました。

• ストレージインスタンスをレプリカセットに結合する。
• ブートストラップvshard（クラスターデータシャーディングメカニズム）;
• フェイルオーバーの設定（転倒した場合のマスターの自動切り替え）。

これらは、すべてのインスタンスが稼働している展開の最終段階です。残念ながら、他のすべてのステップはそのままにしておく必要がありました。

オーケストレーターの選択

サーバー上のコードは、実行できない場合は役に立ちません。Tarantoolインスタンスを開始および停止するためのユーティリティが必要です。ansible-cartridgeには、systemctlサービスファイルを作成し、rpmパッケージを操作するためのタスクが含まれています。しかし、私たちのタスクの特異性は、顧客の閉回路の存在とsudo特権の欠如でした。これは、systemctlを使用できなかったことを意味します。



-すぐに我々は、恒久的なroot権限を必要としないオーケストた supervisordを..。最初にすべてのサーバーにインストールし、ソケットファイルへのアクセスに関するローカルの問題も解決する必要がありました。新しいansibleロールがsupervisordで機能するように見えました。これには、構成ファイルの作成、構成の更新、インスタンスの開始と停止のタスクが含まれています。それはそれを本番環境に入れるのに十分でした。



実験のために、ansible-cartridgeでsupervisordを使用してアプリケーションを実行する機能を追加しました。この方法は柔軟性が低いことが判明し、別のブランチでの完了をまだ待っています。

読み込み時間の短縮

どちらのオーケストレーターを使用しても、インスタンスが起動するまで1時間待つことはできません。しきい値は20分です。インスタンスがこのしきい値より長く使用できない場合、自動クラッシュがトリガーされ、アカウンティングシステムに記録されます。頻繁な事故はチームの主要なパフォーマンスに影響を与え、システム開発の計画を損なう可能性があります。法的に必要な展開のため、プレミアムをまったく失いたくありません。ぜひ、20分以内に保管してください。



事実：ダウンロード時間はデータの量に直接依存します。ログからRAMにレイズする必要があるほど、更新後のインスタンスの起動時間が長くなります。また、同じマシン上のストレージインスタンスがリソースをめぐって競合することも考慮する必要があります。Tarantoolはすべてのプロセッサコアを使用してインデックスを作成します。



私たちの観察に基づくと、memtx_memory



インスタンスあたりのサイズ は40GBを超えてはなりません。この値は、インスタンスのリカバリに20分未満かかる場合に最適です。1つのサーバー上のインスタンスの数は個別に計算され、プロジェクトのインフラストラクチャと密接に関連しています。

モニタリングを接続します

すべてのシステムを監視する必要があり、Tarantoolも例外ではありません。私たちの監視はすぐには現れませんでした。ブロック全体が、必要なアクセスの取得、承認、および環境のセットアップに費やされました。



アプリケーションの開発とプレイブックの作成の過程で、メトリックモジュール（ github）を少し変更しました 。これで、メトリックを、それらが飛んだインスタンスの名前で分割できます-作成されたグローバルラベル。監視システムとの統合の結果、クラスターアプリケーションの全体的な役割が明らかになり ました。新しいタイプの分位数メトリック は、システムの要件の一般化からも生まれました。



これで、システムへの現在の要求数、使用されているメモリのサイズ、レプリケーションラグ、およびその他の多くの主要なメトリックが表示されます。さらに、チャットでの通知を使用して構成されます。最も重大な問題は、自動車事故の一般的なシステムに分類され、排除するための明確なSLAがあります。



ツールについて少し。どこで、何を、どのように入手するかの詳細な説明は、etcdに収集され 、そこからテレグラフエージェント が指示を受け取ります。 JSON形式のメトリックはInfluxDBに保存され ます。Grafanaをビジュアライザーとして使用し 、テンプレートダッシュボードも作成しました 。そして最後に、アラートは kapacitor。



もちろん、これは監視を実装するための唯一のオプションではありません。Prometheusを使用でき 、メトリックは必要な形式で値を指定する方法を知っているだけです。アラートの場合、たとえばzabbixも便利 です。



同僚は、記事「Tarantoolの監視：ログ、メトリック、およびそれらの処理」で、Tarantoolの監視の設定について詳しく教えてくれました 。

ロギングの設定

監視に限定することはできません。システムで何が起こっているかを完全に把握するには、すべての診断を収集する必要があります。これにはログも含まれます。さらに、ログレベルが高いほど、デバッグ情報が多くなり、ログファイルが大きくなります。



ディスク容量は無限ではありません。私たちのアプリケーションは、ピーク負荷時に1日あたり最大1TBのログを生成する可能性があります。このような状況では、ディスクを追加できますが、遅かれ早かれ、空き容量またはプロジェクトの予算が不足します。しかし、トレースなしでデバッグ情報を失いたくはありません！何をすべきか？



展開の段階の1つで、logrotate設定を追加しました ：100MBのファイルをいくつか生のままにして、さらにいくつか圧縮します。通常の操作では、これで24時間以内にローカルの問題を見つけることができます。ログは、厳密に定義されたディレクトリにJSON形式で保存されます。すべてのサーバーがfilebeat実行デーモン アプリケーションのログを収集しに長期保存のためにそれらを送信し、 ElasticSearchを。このアプローチにより、ディスクオーバーフローエラーが発生しなくなり、長期的な問題が発生した場合にシステムパフォーマンスを分析できます。そして、このアプローチは展開にうまく適合します。

ソリューションをスケーリングします

道は長くてとげがあり、かなりの量の錐体がありました。間違いを繰り返さないために、デプロイメントを標準化し、CI / CDバンドル（Gitlab + Jenkins）を使用しました。スケーリングも多くの問題を引き起こし、ソリューションのデバッグには1か月以上かかりました。しかし、私たちは対処しました、そして今、私たちはあなたと私たちの経験を共有する準備ができています。手順を見ていきましょう。



開発者が自分の問題の解決策をすばやく投入し、それを本番環境に確実に提供できるようにするにはどうすればよいですか？彼からジェンキンスファイルを奪う！大胆な境界線の輪郭を描き、それを超えると展開が不可能になることを意味し、開発者にこの道を案内する必要があります。



本格的なサンプルアプリケーションを作成しました。これは同じ方法で展開され、徹底的な出発点です。しかし、私たちはさらに顧客と協力しました。gitリポジトリとJenkinsタスクを設定するテンプレートを自動的に作成するためのユーティリティを作成しました。開発者はすべてについてすべてに1時間もかからず、プロジェクトは本番環境になります。



パイプラインは、標準のコードチェックと環境設定から始まります。さらに、その後の展開のために、いくつかの機能テストゾーンと製品に在庫を置きます。次に、ユニットテストフェーズが始まります。



標準のTarantoolテストフレームワーク luatest（ github）。ユニットテストと統合テストの両方を書き込むことができます。TarantoolCartridgeを実行および構成するための補助モジュールがあります 。また、最近のバージョンでは、カバレッジを有効にでき ます。簡単なコマンドで開始します。

.rocks/bin/luatest --coverage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

テストの最後に、収集された統計は、コードの品質と安全性を評価するためのソフトウェアであるSonarQubeに送信され ます。内部では、QualityGateをすでに構成しています。言語（Lua、Python、SQLなど）に関係なく、アプリケーション内のすべてのコードが検証されます。ただし、Luaには組み込みのハンドラーがないため、カバレッジを一般的な形式で表すために、テストの開始前にインストールされるプラグインがあります。

tarantoolctl rocks install luacov 0.13.0-1             #    coverage
tarantoolctl rocks install luacov-reporters 0.1.0-1    #  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

単純なコンソールバージョンは次のように表示できます。

.rocks/bin/luacov -r summary . && cat ./luacov.report.out
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

SonarQubeのレポートは、次のコマンドによって生成されます。

.rocks/bin/luacov -r sonar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

カバレッジの後、リンターステージが始まります。Tarantoolプラグインの1つでもあるluacheck（ github）を使用してい ます。

tarantoolctl rocks install luacheck 0.26.0-1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

リンターの結果もSonarQubeに送信されます。

.rocks/bin/luacheck --config .luacheckrc --formatter sonar *.lua
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

コードカバレッジ統計とリンターは一緒にカウントされます。品質ゲートを通過するには、すべての条件を満たす必要があります。

• テストによるコードカバレッジは少なくとも80％でなければなりません。
• 変更によって新しい臭いが発生することはありません。
• 重大な問題の総数は0です。
• 重要でない株の総数は5未満です。

Quality Gateを通過した後、アーティファクトをベイク処理する必要があります。我々は、すべてのアプリケーションがTarantoolカートリッジを使用することを決めたので、我々は、使用カートリッジ-CLI（ githubのを）構築するため 。これは、クラスター化されたTarantoolアプリケーションをローカルで実行（実際には開発）するための小さなユーティリティです。彼女はまた、ローカルとDockerの両方でアプリケーションコードを使用してDockerイメージとアーカイブを作成する方法も知っています（たとえば、異なるアーキテクチャのアーティファクトを構築する必要がある場合）。アセンブリ tar.gz



は次のコマンドで実行されます。

cartridge pack tgz --name <nme> --version <vrsion>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

結果のアーカイブは、Artifactoryや Mail.ru CloudStorageなどの任意のリポジトリにアップロードされます 。

ダウンタイムなしで展開

そして、パイプラインの最後のステップはデプロイメント自体です。編集の状態に応じて、ローリングはさまざまなテストゾーンで実行されます。くしゃみには1つのゾーンが割り当てられます。リポジトリにプッシュするたびに、パイプライン全体が起動します。あなたは、外部システムとの相互作用をテストすることができ、いくつかの機能領域は、このために、あなたが作成する必要もあります マージ要求で マスター・リポジトリのブランチを。ただし、本番環境では、変更が受け入れられ、マージボタンが押された後にのみローリングが開始されます。



ダウンタイムのない展開の重要な要素を思い出させてください。

• データセンターの更新。
• レプリカセットのマスターの切り替え。
• アクティブなデータセンターのバランサーを設定します。

アップグレードするときは、バージョンとデータスキーマの互換性を監視する必要があります。いずれかの手順でエラーが発生すると、更新は停止します。



更新は、次のように概略的に表すことができます。





これで、更新にはサーバーの再起動が伴います。いつデプロイを続行できるかを理解するために、インスタンスの状態を待機する別のプレイブックがあります。 Tarantool Cartridgeにはステートマシンがあり、RolesConfigured状態を待機しています 。これは、インスタンスが完全に構成されていることを意味します（そして、私たちにとっては、リクエストを受け入れる準備ができています）。アプリケーションを初めてデプロイする場合は、未構成の状態を待つ必要があります 。



全体として、この図は、ダウンタイムのない展開の概要を示しています。より多くのデータセンターに簡単に拡張できます。必要に応じて、マスターを変更した直後に（つまり、データセンター＃1と一緒に）すべてのバックアップ「アーム」を更新するか、1つずつ更新することができます。



もちろん、私たちは自分たちの開発をオープンソースにするしかないのです。これまでのところ、それらは私のansible-cartridgeフォーク（opomuc / ansible-cartridge）で利用できますが、 これをメインリポジトリのマスターブランチに移動する計画があります。



例はここにあります（ example）。正しく機能するには、サーバーをsupervisord



ユーザー用に構成する必要が あります tarantool



。構成コマンドは ここにあります。アプリケーションを含むアーカイブには、バイナリも含まれている必要があります tarantool



。



ショルダー展開を開始するための一連のコマンド：

#   (  )
ansible-playbook -i hosts.yml playbook.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.0.0-0.tar.gz' \
    --extra-vars 'app_version=1.0.0' \
    --tags supervisor

#     1.2.0

#    dc2
ansible-playbook -i hosts.yml master.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.2.0-0.tar.gz' \
    --limit dc2

#    — dc1
ansible-playbook -i hosts.yml playbook.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.2.0-0.tar.gz' \
    --extra-vars 'app_version=1.2.0' \
    --tags supervisor \
    --limit dc1

#    dc1
ansible-playbook -i hosts.yml master.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.2.0-0.tar.gz' \
    --limit dc1

#    — dc2
ansible-playbook -i hosts.yml playbook.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.2.0-0.tar.gz' \
    --extra-vars 'app_version=1.2.0' \
    --tags supervisor \
    --limit dc2

#   ,    dc1
ansible-playbook -i hosts.yml master.yml \
    -b --become-user tarantool \
    --extra-vars 'base_dir=/data/tarantool' \
    --extra-vars 'cartridge_package_path=./getting-started-app-1.2.0-0.tar.gz' \
    --limit dc1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

このパラメータbase_dir



は、プロジェクトの「ホーム」ディレクトリへのパスを示します 。ロールアウト後、サブディレクトリが作成されます。

• <base_dir>/run
  
  
  
  -制御ソケットおよびpidファイル用。
• <base_dir>/data
  
  
  
  -.snapファイルと.xlogファイル、およびTarantoolCartridge構成の場合。
• <base_dir>/conf
  
  
  
  -アプリケーション設定および特定のインスタンス用。
• <base_dir>/releases
  
  
  
  -バージョン管理とソースコード用。
• <base_dir>/instances
  
  
  
  -アプリケーションの各インスタンスの現在のバージョンへのリンク。

パラメータ cartridge_package_path



はそれ自体を物語っていますが、特殊性があります。

• パスがhttp://
  
  
  
  またはhttps://
  
  
  
  で始まる場合、アーティファクトはネットワークからプリロードされます（たとえば、その隣で発生したアーティファクトから）。
• それ以外の場合、ファイルはローカルで検索されます

このパラメーター app_version



は、フォルダー内のバージョン管理に使用されます <base_dir>/releases



。デフォルトは latest



です。



タグ supervisor



は、オーケストレーターとして使用されることを意味し supervisord



ます。



展開を開始するための多くのオプションがありますが、最も信頼できるのは古き良きもの Makefile



です。条件付きコマンド make deploy



は任意のCI \ CDに含めることができ、すべてがまったく同じように機能します。

結果

それで全部です！これで、Jenkinsに既製のパイプラインができ、仲介業者が排除され、変更の配信速度が非常識になりました。ユーザー数は増加しており、本番環境では、当社のソリューションのみを使用してすでに500のインスタンスがデプロイされています。成長する余地があります。



また、デプロイプロセス自体は理想からはほど遠いものの、DevOpsプロセスをさらに開発するための強固な基盤を提供します。システムを本番環境に迅速に提供し、頻繁に編集することを恐れないように、実装を安全に行うことができます。



また、モノリスを持ち込むことは不可能であり、その普及を期待することも私たちの教訓になります。プレイブックの分解、インストールの各段階での役割の割り当て、在庫を柔軟に提示する方法が必要です。いつか私たちの開発はマスターに含まれ、すべてがさらに良くなるでしょう！

リンク

• ansible-cartridgeのステップバイステップガイド：
  
  
  
  
  • パート1
  • パート2
• TarantoolCartridgeについてはこちらをご覧ください。
• Kubernetesへのデプロイについて：
  
  
  
  
  • KubernetesでTarantoolカートリッジを使用するためのガイド。
  • ウェビナー-TarantoolCartridgeアプリケーションをKubernetesMCSクラスターにデプロイする
• Tarantoolの監視：ログ、メトリック、およびそれらの処理。
• ヘルプが必要な場合は、Telegramチャットにお問い合わせください。