過去数年間、当社のネットワークは、何十万ものライブストリーミングされたスポーツイベント、大規模なソフトウェアダウンロード、数十億時間に及ぶストリーミングビデオコンテンツ、そしてリアルタイムの応答性とグローバルに一貫したパフォーマンスを必要とする何千ものウェブアプリケーションからの要求をサポートしてきた。 2015年以降、グローバルネットワークは250 Tbps以上に拡大し、300 PoPで数千台の新しいサーバーが必要になった。
常に成長し変化し続けるネットワークフットプリントの導入という課題に対応するため、運用チームはStackStormを使用してIT自動化プラットフォームを開発した。 これは、当社のチームがサーバーインフラストラクチャをデプロイ、変更、修復、廃止する方法を変革した大きな飛躍であり、当社のグローバルネットワーク全体のサーバー人口の95%以上に及ぶ。
自動化プラットフォームを構築した方法を見てみよう。
- 3年以内に12,000台以上のサーバーをネットワークに追加
- チケット生成を自動化し、チケットがない問題を解決する場合もある。
- チームがリアルタイムでコラボレーションできるように、チームにツールを提供する。
- 一連の手動手順に要するエンジニアの時間を短縮
StackStormをプロジェクトザリガニにカスタマイズする
IT自動化プラットフォームの価値と成熟度の向上を認識し、2015年にプロジェクト名「Crayfish」の下にインフラストラクチャ自動化チームを結成。 IT自動化ソリューションの開発に本格的に着手した。 プロジェクトの名前の選択は、私たちが今も使っているもので、意図的なものだった。 私たちの道具には昔から魚や航海のテーマがあったが、それ以上にザリガニを選んだのは、ザリガニがフィルターフィーダーとして機能し、彼らが住んでいる環境をきれいに保つのに役立つからだ。
当初は独自のIT自動化フレームワークを開発することを検討していたが、StackStormに独自の要件と規模をサポートする機能強化を追加することで、最も効果的に前進できると早くから判断した。 StackStormはオープンソースのイベント駆動型プラットフォームであり、DevOps自動化のための「コードとしてのインフラストラクチャ」アプローチをサポートしている。 イベントに基づいたワークフローの実行が得意で、オペレーションチーム全体で使用するSlackと統合でき、ネイティブのChatOpsサポートを備えている。
StackStormには、必要な規模で実行できるように、いくつかの設定変更が加えられている。 主に、実行中のサービスインスタンスの数を増やし、データ保持を減らすことが含まれていた。 プロジェクトを開始したとき、私たちのネットワークは8,000台のサーバーで構成されていた。 現在は20,000台のサーバーがあり、増え続けている。 我々のスケーラビリティの鍵は、単一のStackStormインスタンスにすべてを処理させようとするのではなく、任意の数のStackStormインスタンスをワーカーとして実行できることである。 下の図に示すように、これは我々が開発したPolicy Engineによって可能になったものであり、我々のビジネスロジックに基づいてStackStormへのリクエストの送信をゲートする。 Policy Engineは要求をキューに入れ、ポリシーが安全であると判断したときに自動的に実行することができる。 これらのポリシーは、同時実行性、容量、トラフィック、本番ステータス、インフラストラクチャ、ブラックリスト、および障害率を監視する。
サブミッション要求はPolicy Engineインスタンスを経由して任意の数のStackStormワーカーにルーティングされ、事実上無制限のスケーラビリティを実現する。
部族の知識を体系化する
IT自動化プロジェクトの基本的なアプローチは、既存のプロセスとワークフローをキャプチャし、手動による介入なしにワークフローステップを実装できるコードに変換し、コード化されたワークフローを中央リポジトリに格納し、他の自動化の一部として、またはChatOpsコマンドを介して必要に応じて呼び出すことができる。
プロジェクトが開始されると、ザリガニチームは組織全体の既存のワークフローとプロセスを把握した。 幸いにも、Network Operation Center (NOC)、Data Center Operations、SysOpsなどの異なるグループで使われている最も重要なプロセスの大部分は十分に文書化されており、Pythonを使ってすぐにコード化でき、ザリガニに追加された。
たとえば、NOCが再起動ワークフローを実装したい場合、さまざまなポリシーチェックに基づいてマシン上で動作しても安全であることを検証する必要がある。 例えば、サーバが稼働している場合、システムは接続を切断してステータスを更新する。 次に、実際の再起動と、マシンが本番環境に戻る前に本番環境に準備ができていることを確認するために必要な手順を実行する。
確かにエッジケースはたくさんあった。 最も難しかったのは、文書化に至らなかったプロセスである。 これらの部族知識の事例では、部門横断的な協力と専門知識を持つ個人との対話が必要であった。 自動化の取り組みの副次的な利点の1つは、この知識を取得して、組織内に確実に保存できることだった。
特定のタスクで何が起こっているのか、特定の問題を解決する方法を理解している複数のエンジニアや技術者と接続することで、特定のタスクをより効率的に処理する方法を特定することさえできた。 チームメンバーによって知識のレベルが異なる場合もあることがわかった。 そこで、全員の知性を集め、全員が最も効率的なソリューションを提供することに合意した単一のワークフローを開発する。
新しいサーバをオンデマンドで導入
サーバー管理の簡素化、サーバーダウンタイムの削減、サーバー導入の迅速化など、当社のIT運用をさまざまなレベルで変革してきた。 2018年だけで、ITOpsは当社のグローバルネットワークに22 Tbpsの容量を追加した。 ザリガニの自動化がなければ、数千台のサーバーを追加することはできなかっただろう。 そして、それは大幅にスタッフレベルを上げることなく達成された。
現在、ザリガニは約20種類のサーバーに対して堅牢な自動化を提供している。 我々の組織では、サーバタイプを多かれ少なかれ同じサービスを実行するサーバのグループとして定義する。 異なるアプリケーションが異なるサーバタイプで実行され、各サーバタイプが本番環境で異なるサポートニーズを持つ。 現在、ザリガニは約10種類のサーバーのライフサイクル全体をサポートしており、さらに約10種類のサーバーのほとんどの修復、修正、パッチ適用が可能である。 また、約40から50以上の様々な程度の支持を提供する。 最も広く導入されているサーバータイプに焦点を当てたため、ザリガニは世界のサーバー人口の約96%をサポートしている。
ザリガニの使用はCDNの全体的なパフォーマンスの向上と予期しない出来事に対応する能力をもたらした。 当社のネットワークは、たとえば、より多くのサーバーを実稼働状態に維持し、ピークトラフィック時にサーバーを生産から削除することの中断を減らすことで、主要なスポーツイベントストリームやピークソフトウェアダウンロードからの大量の、増加し続けるトラフィックをサポートするために十分に装備されている。
パフォーマンスの観点からザリガニがなぜ必要なのかということに、私たちのスケールが貢献している。 企業にデータセンターが1つある場合は、ダウンタイムをスケジュールして、そのデータセンターのニーズを常に把握できる。 しかし、以下のネットワークマップに示されているように、ほぼすべてのタイムゾーンのデータセンターについて話している場合、異なるプロファイル、使用状況、および使用時間に対処する必要がある。 これらすべての要素をケースバイケースで考慮することは非常に複雑であるが、ザリガニはそれを容易に扱う。
ザリガニでは、プロビジョニングやアップグレードなどのタスクを自動的にスケジュールすることができるが、システムは現地のニーズに対応できるほどスマートである。 ラトビアのニュースイベントが、ラトビアのすべてのサーバーを再プロビジョニングしたいときにビデオストリーミングが大幅に急増したとしよう。 ザリガニとメトリクス収集システムが統合されているため、トラフィックが増加し、再プロビジョニングが停止する。 必要に応じて、より多くのサーバを本番環境に投入することも可能である。
インフラストラクチャ障害がサービス停止になる前に検出
ザリガニやその他の監視システムは、個々のサーバーのダウンタイムと修復時間を大幅に削減する。 当社のシステムは、問題や障害がないかネットワークを継続的に監視し、自動的にチケットを作成したり、修正を直接適用したりできる。 自動化されたシステムでは、スタッフはネットワークエラーを発見するために「ガラスに目を向ける」必要がない。コンピュータは退屈したり疲れたりせず、継続的に監視している。
この方法で行うことができるチェックの量にはほとんど制限がない。 私たちのメトリックシステムは、マシンを生産から外す必要のないハードウェアチェックを継続的に実行する一方、別のシステムは不良値を探し、問題が見つかったときにザリガニを呼び出してマシンをチェックする。 このアプローチでは、ハードウェア障害を非常に早い段階で検出できる。
例えば、ハードドライブが故障し始めていることがメトリックで示された場合、自動システムは、影響を受けたマシンのエラーを検証し、どのハードドライブがどのスロットで故障したか、シールド番号などの障害に関する詳細を収集するザリガニのワークフローを開始する。 次に、Data Center Operationsグループ用に特別に作成されたチケットを作成し、技術者を派遣して交換品をインストールする。
歴史的に、複数の部門がステップ間で調整または引き渡しを必要とする手動ワークフローは、途中で大幅な遅延をもたらした。 自動化されたワークフローでは、チケットキューでリクエストがポップアップするのを待つ日数ではなく、完了までの時間が分になる場合がある。 これにより、システムとアプリケーションを最もよく知っている個々の運用チームの手により多くの制御が可能になる。
エンジニアの生産性を向上させるツールを提供する
NOC作業に対する以前のアプローチでは、コマンドを発行して、物事が起こるのを待つことになっていた。 NOC技術者がサーバが正常にシャットダウンするのを10分、20分、または30分待っている場合は、その理由を尋ねる必要がある。 時間の使い方は? ザリガニは並行して多くの処刑を行うことができる また、前述したように、ザリガニは水平に伸びるように設計されている。 だから、もっと仕事が必要なら、新しいノードを追加することができる。 突然、多くの作業を一度に行わなければならないことに気付いた場合、CDN全体でいくつかのノードをスケールアップし、スケールダウンすることができる。
また、技術者は、一度に作業できる機械の数に関して、それほど多くのメモリしか持っていない。 トラックを失ったりエラーを起こすことなく、異なる状態の5台または6台以上のマシンを処理できるのは、最も優れたマルチタスク処理者だけである。 しかしザリガニなら、いろいろな作業を飛び越える必要はなく、命令を出して先に進むことができる。
ソフトウェアインフラストラクチャチームとシステム運用チームによって開発された既存のスマートプロビジョニングシステムに基づいて構築されたサーバーライフサイクルの他の側面は、ザリガニ社内で完全にサポートされ、オペレーティングシステムの更新、サーバーのプロビジョニングまたは再プロビジョニングファームウェアの更新、セキュリティパッチなど、主に自律的に行われる。 新しいパッチがリリースされると、ザリガニはパッチがリリースされても問題ないことを確認するための検証テストを高速化する。
ザリガニはSlackと統合されているため、通常のITプロセスをサポートし、ニーズや要件の変化に応じてコラボレーション作業を容易にする。 チームは、変更の実装を単一の部門で待つのではなく、手動プロセスを自動化されたワークフローとして定義できるようになった。 エンドユーザーにワークフローを提供し、オンデマンドで実行できるようにする。 ワークフローを安全に実行できるタイミングを制限するポリシーも実装できる。 これにより、データセンターのサーバの前に立っているエンジニアが、作業したいサーバの生産状況を変更するコマンドを発行することもできる。
最終的な考え
数千の顧客が毎日2万台以上のサーバーからなる当社のグローバルネットワーク上でテラバイト規模のデータを送信しているため、StackStormの実装は、当社のサービスを健全かつ安全に保つために不可欠な運用ツールとなっている。 これにより、ネットワークを迅速に拡張して顧客の需要に対応しながら、動的な変化や予期しないトラフィックの急増にもかかわらず、より優れたパフォーマンスを提供できるようになった。 このような運用の俊敏性により、ストリーミングメディアやウェブアプリケーションの需要に合わせて拡張できる信頼性の高いサービスプロバイダーとなっている。
ほとんどの組織は、当社と同じ規模では運営されていないが、自動化を魅力的にする運用上の利害関係がいくつか存在する。その中には、次のような機能が含まれる。
- 開発者をより高い収益を生み出す作業に集中させる
- 日常業務や日常業務を標準化する。
- 部門間のコラボレーションを改善する。
- サーバのダウンタイムを短縮。
- ファームウェアアップデートとセキュリティパッチを実装することでセキュリティを向上させる。
IT自動化への移行は投資収益率を非常に高めることは間違いないが、適切な理由で確実に移行することが重要である。 自動化は、エンジニアがより生産的で熟練したツールを提供し、改善に集中できるようにする方法であると考えることが良いアプローチである。
ワークフローベースの自動化への移行は、部族の知識を社会化し、体系化する優れた方法である。 誰もが独自のアプローチを持つのではなく、部族をまとめ、共通のワークフローを考え、誰もが得た将来の知識を単一の収益に貢献できるようにする。