4 人のエンジニア、7000 台のサーバー、XNUMX つの世界的パンデミック

おい、ハブル！ 記事の翻訳をご紹介します 「4 人のエンジニア、7000 台のサーバー、そして XNUMX つの世界的パンデミック」 アディブ・ドー著。

この見出しを見て背筋が少し震えるほどではない場合は、次の段落にスキップするか、次の記事に特化したページにアクセスしてください。 会社でのキャリア - 話したいと思います。

私たちは誰ですか

私たちはコードを書くこととハードウェアを扱うことが大好きな 4 人のペンギンのチームです。 余暇には、米国内の 7000 つの異なるデータ センターに分散された、Linux を実行する 3 台を超える物理サーバーの導入、保守、運用を担当しています。

また、現場から 10 km 離れた地中海のビーチから車ですぐの場所にある快適な自社オフィスからこの作業を行う機会もありました。

スケールの問題

初期投資が比較的低いため、スタートアップがインフラストラクチャをクラウドでホストすることから始めるのは理にかなっていますが、私たち Outbrain は独自のサーバーを使用することにしました。 これは、クラウドインフラストラクチャのコストが、一定レベルまで開発した後、データセンターにある自社の機器を運用するコストをはるかに上回るためです。 さらに、サーバーは最高レベルの制御機能とトラブルシューティング機能を提供します。

私たちが発展するにつれて、問題は常に身近にあります。 しかも、彼らはたいてい集団でやって来ます。 サーバーのライフサイクル管理では、サーバーの数が急速に増加した状況でも適切に機能できるように、継続的な自己改善が必要です。 データセンター内のサーバー グループを管理するソフトウェア方式は、すぐに扱いにくくなります。 QoS 標準を満たしながら障害を検出、トラブルシューティング、軽減するには、非常に多様なハードウェア、さまざまなワークロード、アップグレード期限、その他誰も心配したくない事柄をうまく処理する必要があります。

ドメインをマスターする

これらの問題の多くを解決するために、Outbrain のサーバーのライフサイクルを主要コンポーネントに分割し、それらをドメインと呼びました。 たとえば、XNUMX つのドメインは機器要件をカバーし、別のドメインは在庫ライフ サイクルに関連する物流をカバーし、XNUMX 番目のドメインは現場担当者とのコミュニケーションをカバーします。 ハードウェアの可観測性に関してはもう XNUMX つありますが、すべての点については説明しません。 私たちの目標は、コードを使用してドメインを抽象化できるようにドメインを研究して定義することでした。 実用的な抽象化が開発されると、それは手動プロセスに転送され、展開、テスト、改良が行われます。 最後に、ドメインは API を介して他のドメインと統合するように構成され、展開可能、テスト可能、観察可能な総合的で動的、進化し続けるハードウェア ライフサイクル システムを形成します。 他のすべての生産システムと同様です。

このアプローチを採用することで、ツールと自動化を作成することで、多くの問題を正しく解決できるようになりました。

ドメインが必要

電子メールとスプレッドシートは初期の需要を満たす有効な方法でしたが、特にサーバーの数と受信リクエストの量が一定のレベルに達すると、成功したソリューションとは言えませんでした。 急速な拡大に直面して受信リクエストをより適切に整理し、優先順位を付けるには、以下を提供できるチケット システムを使用する必要がありました。

• 関連するフィールドのみのビューをカスタマイズする機能 (シンプル)
• オープン API (拡張可能)
• 私たちのチームには知られています（理解しています）
• 既存のワークフローとの統合（統合）

私たちは Jira を使用してスプリントと内部タスクを管理しているため、クライアントがチケットを送信して結果を追跡できるようにする別のプロジェクトを作成することにしました。 受信リクエストと内部タスクの管理に Jira を使用することで、すべてのプロセスを全体的に確認できる単一のカンバン ボードを作成できるようになりました。 私たちの内部の「クライアント」は、追加タスク (ツールの改善、バグの修正など) のそれほど重要ではない詳細には踏み込まず、機器のリクエストのみを認識していました。

Jira のカンバン ボード

おまけに、キューと優先順位が誰にでも見えるようになったことで、特定のリクエストが「キューのどこ」にあるのか、そのリクエストの前に何があったのかを理解できるようになりました。 これにより、所有者は当社に連絡することなく、自分のリクエストの優先順位を変更できるようになりました。 ドラッグすればそれで終わりです。 また、Jira で生成されたメトリクスに基づいて、リクエスト タイプに応じて SLA を監視し、評価することもできました。

機器ライフサイクル領域

各サーバー ラックで使用されるハードウェアの管理の複雑さを想像してみてください。 さらに悪いことに、多くのハードウェア (RAM、ROM) が倉庫からサーバー ルームに移動され、また倉庫に戻される可能性があることです。 また、故障したり、償却されて交換され、交換/修理のためにサプライヤーに返送されることもあります。 これらすべてを、機器の物理的なメンテナンスに携わるコロケーション サービスの従業員に伝える必要があります。 これらの問題を解決するために、私たちはフロッピーと呼ばれる内部ツールを作成しました。 彼の任務は次のとおりです。

• 現場担当者とのコミュニケーションの管理、すべての情報の集約。
• 機器メンテナンス ジョブが完了して検証されるたびに、「倉庫」データを更新します。

次に、ウェアハウスは Grafana を使用して視覚化され、すべてのメトリクスをプロットするために使用されます。 したがって、私たちは倉庫の視覚化とその他の生産ニーズに同じツールを使用します。

グラファナの倉庫設備制御パネル

保証期間中のサーバー デバイスの場合は、Dispatcher と呼ばれる別のツールを使用します。 彼：

• システムログを収集します。
• ベンダーが要求する形式でレポートを生成します。
• API 経由でベンダーからのリクエストを作成します。
• 進行状況をさらに追跡するために、アプリケーション識別子を受信して​​保存します。

当社の請求が受理されると (通常は営業時間内)、スペアパーツは適切なデータセンターに送られ、スタッフが受け取ります。

Jenkins コンソールの出力

コミュニケーションドメイン

増え続けるキャパシティを必要とする当社のビジネスの急速な成長に対応するために、地元のデータセンターの技術専門家との連携方法を適応させる必要がありました。 当初スケールアップが新しいサーバーの購入を意味していたとしても、(Kubernetes への移行に基づく) 統合プロジェクトの後は、まったく異なるものになりました。 「ラックの追加」から「サーバーの再利用」への進化。

新しいアプローチを使用するには、データセンター担当者とより快適に対話できる新しいツールも必要でした。 これらのツールは次の目的で必要でした。

• シンプルさ;
• 自律性。
• 効率;
• 信頼性。

私たちはチェーンから自分たちを排除し、技術者がサーバー機器を直接操作できるように作業を構造化する必要がありました。 私たちの介入なしに、また作業量、労働時間、設備の可用性などに関するこれらすべての問題を定期的に提起することなく。

これを実現するために、すべてのデータセンターに iPad を設置しました。 サーバーに接続すると、次のことが起こります。

• デバイスは、このサーバーが実際に何らかの作業を必要とすることを確認します。
• サーバー上で実行されているアプリケーションは (必要に応じて) 閉じられます。
• 必要な手順を説明する一連の作業手順が Slack チャネルに投稿されます。
• 作業が完了すると、デバイスはサーバーの最終状態が正しいかどうかをチェックします。
• 必要に応じてアプリケーションを再起動します。

さらに、技術者を支援するための Slack ボットも用意しました。 幅広い機能のおかげで (私たちは常に機能を拡張していました)、ボットは彼らの仕事を容易にし、私たちの生活をずっと楽にしてくれました。 このようにして、サーバーの再利用と保守のプロセスのほとんどを最適化し、ワークフローから自分たちを排除しました。

当社のデータセンターの XNUMX つにある iPad

ハードウェアドメイン

データセンター インフラストラクチャを確実に拡張するには、次のような各コンポーネントを適切に可視化する必要があります。

• ハードウェア障害の検出
• サーバーの状態 (アクティブ、ホスト、ゾンビなど)
• 消費電力
• ファームウェアのバージョン
• このビジネス全体の分析

当社のソリューションにより、機器をいつ、どこで、どのように購入するかを、実際に必要になる前に決定できるようになります。 また、さまざまな機器の負荷レベルを判断することで、リソースの割り当てを改善することができました。 特にエネルギー消費。 私たちは、サーバーをラックに設置して電源に接続する前から、サーバーのライフサイクル全体を通して、そして最終的に廃棄されるまで、サーバーの配置について情報に基づいた決定を下すことができるようになりました。

Grafana のエネルギー ダッシュボード

そして、新型コロナウイルス感染症が出​​現しました...

私たちのチームは、メディア企業やパブリッシャーがオンラインで訪問者が興味のある関連コンテンツ、製品、サービスを見つけられるようにするテクノロジーを開発しています。 当社のインフラストラクチャは、エキサイティングなニュースがリリースされたときに生成されるトラフィックを処理するように設計されています。

新型コロナウイルス感染症をめぐるメディアの集中的な報道と交通量の増加により、私たちはこれらのプレッシャーに対処する方法を早急に学ぶ必要がありました。 さらに、これらすべては、サプライチェーンが寸断され、スタッフのほとんどが在宅している世界的危機の最中に行われなければなりませんでした。

しかし、すでに述べたように、私たちのモデルはすでに次のことを前提としています。

• データセンター内の機器のほとんどは、物理的にアクセスできません。
•  私たちはほとんどすべての物理的な作業をリモートで行います。
• 作業は非同期かつ自律的に大規模に実行されます。
• 新しい機器を購入するのではなく、「部品から構築する」方法を使用して機器の需要に応えます。
• 当社には、日常的な修理を行うだけでなく、新しいものを作成できる倉庫があります。

したがって、多くの企業がデータセンターへの物理的なアクセスを妨げる世界的な規制は、当社にはほとんど影響を与えず、スペアパーツやサーバーに関しては、はい、機器の安定した稼働を確保するよう努めました。 ただし、これは、一部のハードウェアが利用できないことが突然判明した場合に起こり得るインシデントを防ぐ目的で行われました。 現在の需要に応えることを目標とせずに、確実に予備が埋まるようにしました。

要約すると、データセンター業界における私たちのアプローチは、優れたコード設計の原則をデータセンターの物理管理に適用できることを証明していると言いたいのです。 そしておそらくあなたはそれが面白いと思うでしょう。

オリジナル： タイプ

出所： habr.com