This post is also available in the following languages. Chinese

Argo Workflowsを使ってLINEのBaremetalセットアップを自動化した話

Kodai Matsumoto2022-08-15

Infrastructure Engineer at LINE Corporation.

こんにちは、LINE ITサービスセンターシステム室の松本です。この記事では私が2019に新卒としてLINEに入社して以来携わってきた、LINEのBaremetalセットアップの自動化に関するプロジェクトについてご紹介したいと思います。

Verda Baremetal as a Serviceについて

LINEではOpenStackベースのプライベートクラウドサービスであるVerdaを通じて、LINEで運営しているサービスを担当する社内の開発者へ、VMやストレージといったインフラリソースの提供を行っています。Verdaには様々なサービスがありますが、その中の1つにBaremetal as a Serviceという物理サーバを使用した専有型のコンピューティングリソースを提供する仕組みがあります。このBaremetal as a Serviceでは、通常の物理サーバ上に直接OSをインストールし使用することにより、仮想化技術等を利用した際に発生するオーバーヘッドやノイジーネイバーといった問題を気にすることなくサーバを利用することができます。また、大量のデータを扱うLINEというサービスの性質上、社内で運用されている大型のストレージクラスターも複数あり、モデルによっては大容量/大量のディスクを収容可能な物理サーバの需要は現在でも比較的高く推移しています。

なぜBaremetal as a Serviceをやるのか

VerdaによるBaremetal as a Serviceの提供以前は、基本的に全て社内開発者からの申請ベースによるサーバ要求とそれに応じたサーバ構築を行っていました。このような以前の運用では、個別の申請に対して都度人の手によるOSのインストールなどの作業が必要になったり、サーバの要求から実際にサーバが提供されるまでのデリバリー時間が長くなってしまうなど多くの問題がありました。またLINEで扱うサーバ台数が急激に増加していったことによって、これらの作業を人の手によって行うのが現実的ではなくなってきてしまったというのもあります。このような問題を踏まえ、VerdaのBaremetal as a ServiceではVerdaのDashboard上から通常のVMと同じ感覚でBaremetal Instanceの作成を行えるような仕組みを整備し、Baremetal作成時のOSインストールの自動化やBaremetal削除、リビルド時といった処理が完全に自動化されています。これにより、我々Baremetalを提供する側の運用コストの削減と開発者にBaremetalを提供するまでのデリバリー時間の大幅な短縮が達成されています。

Baremetal初期セットアッププロセスについて

Baremetal as a Serviceには、物理サーバを直接使用するという特性上、様々な初期セットアッププロセスが存在します。

(ラックマウント/結線作業)
資産情報の登録
BIOSやBMCの設定
OSのインストール
1. 本来であればBaremetal初期セットアップにOSインストールは必要ありませんが、サーバのハードウェアの故障や構成パーツが正しいかどうかを確認するために、LINEでは事前に複数回のOSインストールテストをすべてのサーバに対し実施しています。
プライベートクラウドサービスVerdaへの登録

初期セットアッププロセスを大きく分類するとこのようになります。数にするとそこまでセットアッププロセス自体は多くありませんが、LINEのような数万台規模のサーバを扱う環境では、年間約1万台の物理サーバが新規で追加され、多いときでは1度のサーバ増設台数が数千台に上ることもあります。このような環境でBIOSの設定やOSのインストール作業を人の手によるマニュアルオペレーションで実施するのは非常に大変だということをご理解いただけるかと思います。しかしながら、今回紹介するセットアッププロセスの自動化を行うプロジェクト開始以前は実際に人の手によるマニュアルオペレーションでこれらの作業が実施されていました。その頃にあった課題点を簡単にまとめると以下のようになります。

単純に扱うサーバ台数が多いこと
セットアップ、トラブルシューティング共にサーバやLINEのインフラに関する深い知識が要求され新規メンバーなどへの共有が大変
作業内容に複雑な依存関係があり手作業で実施しながら、細かく作業状況を管理する必要がある
作業者による作業内容に微妙な違いがあり、一定の品質を担保することが難しい
人の手による作業と確認である以上、初期セットアップ中のサーバ初期不良やハードウェア故障が見逃されてしまう事例がしばしばあった

このような課題を抱えながら、非常に労力と時間のかかる作業を行っていました。特に5.は開発者がVerdaのDashboard上からBaremetalの作成を行ったタイミングで初めて問題が発覚するため、開発者とBaremetalを管理する担当者双方で大きなストレスポイントになっていました。そこでこれらの課題を解決し、Baremetal初期セットアッププロセスを自動的に実施するシステムを独自に開発し運用するプロジェクトを開始しました。

BSIPプロジェクト

BSIPは前述のBaremetal初期セットアッププロセスの自動化を目的としたプロジェクトです。BSIPではBaremetal特有の泥臭い初期セットアッププロセスを可能な限り自動化し、インフラオペレーションコストの削減を目標としています。BSIPでは依存関係のあるBaremetal初期セットアッププロセスをDAG(有向非巡回グラフ)で表現し、Argo WorkflowsのWorkflowとして処理を行っています。

Argo Workflowsとは

Argo Workflowsとは、CNCFのインキュベーション・プロジェクトであるArgoプロジェクトから提供されているKubernetes-Native Workflow Engineです。Argoプロジェクト自体は、Kubernetes環境とGitOpsでおなじみのArgo CDでご存じの方も多いかと思います。Argo WorkflowsはKubernetes-Native環境での利用を想定しており、すべてのリソースがKubernetesのCRDとして実装されています。ここでArgo Workflowsの特徴を簡単にまとめてみます。

ワークフローの各ステップ処理をコンテナとして実行する
複数の処理ステップをワークフローと定義したり、DAGを使用して処理ステップ間の依存関係を定義したりすることが可能
Kubernetes-Nativeという特徴を活かし、大規模なワークフロー処理にもスケールアウトといったアプローチを容易に取ることが可能

このような特徴がありますが、今回のBSIPでArgo Workflowsを採用した理由は大きく2つあります。
1つ目は、もともと私の所属している組織でKubernetes-Native環境の推進を行っていたことです。従来VMといったレガシーなインフラリソースを使用してデプロイしていた社内システム等を可能な限りコンテナ化することにより、Kubernetes-Native環境でGitOpsといったデプロイ戦略を適用しようという活動です。今回のArgo WorkflowsもKubernetes-Native環境での利用を前提としており、現在のチーム内のトレンドに適したものでした。また、私自身Kubernetesのエコシステムに関するナレッジは比較的豊富に持っている自信もあったため、個人的な相性が良さそうだったというものもあります。
2つ目は、Argo Workflows自体が比較的大規模なワークフローの実行を前提として考えられている点です。これは前述したとおりKubernetes-Nativeという特徴を活かし、スケールアウトといったアプローチを比較的容易に取ることができます。今回のBSIPでは、一度のBaremetalセットアップ台数が多いときで数千台規模になることが最初のうちから想定されていました。そこで、スケールアウトといったアプローチを容易に取ることが可能なArgo Workflowsを選択したというのもあります。

Workflow

Argo Workflows では Workflow という単位で、定義された一連の処理を実行します。ここではサンプル Workflow をご紹介します。Workflow の Manifest にはそれぞれの処理を行うステップとそれらのステップを一連のワークフロー処理として実行する情報が入っています。DAG を使用することによりステップ間に依存関係を持たせることも可能で、使い方次第で複雑な依存関係を持ったワークフロー処理も実現可能です。

entrypoint: hello-hello-hello
templates:
- name: hello-hello-hello
  steps:
  - - name: hello1
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello1"}]
  - - name: hello2a
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello2a"}]
    - name: hello2b
      template: whalesay
      arguments:
        parameters: [{name: message, value: "hello2b"}]

BSIPと Argo Workflows

BSIPではBaremetal初期セットアッププロセスをArgo WorkflowsのWorkflowTemplateで定義しています。WorkflowTemplateはArgo WorkflowsのCRDの1つで名前の通りWorkflowの生成する際のTemplateとして扱えるリソースです。BSIPでは基本的にはセットアップを行う対象のサーバごとにこの WorkflowTemplateからWorkflowを作成し、個別のWorkflowでそれぞれの対象サーバの初期セットアッププロセスを実行するようになっています。これは、BSIPの要件として特定のセットアッププロセスが他のセットアッププロセスに影響を受けないようにするということが定められているためです。例えば、100台のサーバを同時にセットアップすることを想定した場合、仮に1台のサーバに何らかのハードウェア障害といった問題が発生した際に他のセットアッププロセスが止まったりしないように考慮されているということです。これは至極当たり前のことのように聞こえますが、LINEのような扱うサーバ台数の比較的多い環境では重要なポイントです。

ここからBSIPで使用しているWorkflowTemplateを一部紹介します。この部分ではBIOSの設定を行っています。予めcheck-bios-settingsのステップで現在の対象サーバのBIOS情報を取得し、LINEで使用しているBIOS設定内容と異なる場合は次のステップで正しいBIOS設定を行うようになっています。Argo Workflows では一つ前のステップの処理結果を判断して次に実行するステップを制御可能なため、BSIPではこの機能をうまく利用し設定が正しい場合はBIOSの設定を行う次のステップをスキップするような制御を行っています。

- name: check-bios-settings
  dependencies:
    - polling-health-check-ipmi
  template: bsip-task
  continueOn:
    failed: true
  arguments:
    parameters:
      - name: taskName
        value: check-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: set-bios-settings
　　# BIOS設定値が正しくない場合のみBIOS設定のステップを実行する
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - check-bios-settings
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: set-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: bios-settings-apply-hard-reboot
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - set-bios-settings
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: hard-reboot
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"
- name: polling-check-bios-settings
  when: "{{tasks.check-bios-settings.status}} == Failed"
  dependencies:
    - bios-settings-apply-hard-reboot
  template: bsip-task
  arguments:
    parameters:
      - name: taskName
        value: polling-check-bios-settings
    artifacts:
      - name: manifest
        from: "{{workflow.outputs.artifacts.manifest}}"

LINEのBaremetal初期セットアップの中には、サーバ自体の初期不良やハードウェア故障を事前に取り除くため、実際にBaremetalインスタンスの作成とOSインストールをテストで実施するものがあります。これは、社内の開発者へ最終的にBaremetalを提供したタイミングで発生するトラブルを事前に取り除くために実施しているものです。これらの作業もArgo Workflows上のワークフロー処理で必要なシステムと連携し、PXE Boot等を利用して完全自動でインストールテストとテスト完了後のチェック作業まで行われるようになっています。

このようにして現在のBSIPでは1つの物理サーバにつき17ステップ程度の初期セットアッププロセスを完全自動で実施しています。

再実行が容易であること

Baremetal というのは物理サーバを扱う特性上どうしても、初期不良やハードウェア障害のサーバが一定数出てきます。このようなサーバがあった場合は、当然故障箇所を修理し再度セットアップをやり直すといったことを行う必要があります。このような場合に備えてセットアップ処理を何度でもやり直すことができる必要があります。BSIPでは1つ 1 つのセットアップ処理が安全に再実行可能なようにデザインされており、万が一セットアップのやり直し等が発生した場合にも、Workflow を再度作成するだけで再セットアップが行えるようになっています。

GitOpsによるBaremetal管理

今回の記事からは少し脱線しますが、LINEにおけるBaremetal管理手法に関しても簡単にご紹介したいと思います。現在のLINEではBaremetalで使用する物理サーバの管理をGitベースで行うようになっています。すべてのBaremetal情報をGit上のYAMLファイルで宣言的に管理されており、YAMLファイル上のBaremetal情報をArgoCDを使用して、OpenStackなどの関連システムにデプロイしています。

servers:
  server1:
    baremetal_ipmi_mac: 00:00:00:00:00:00
    baremetal_private_ip: 192.168.1.1
    baremetal_private_mac: 00:00:00:00:00:00
    baremetal_flavor_aggregate: FLAVOR1
    baremetal_dc_aggregate: Tokyo
    baremetal_private_network_aggregate: PRIVATE_NETWORK
    baremetal_public_network_aggregate: PUBLIC_NETWORK
  server2:
    baremetal_ipmi_mac: 00:00:00:00:00:00
    baremetal_private_ip: 192.168.1.2
    baremetal_private_mac: 00:00:00:00:00:00
    baremetal_flavor_aggregate: FLAVOR2
    baremetal_dc_aggregate: Tokyo
    baremetal_private_network_aggregate: PRIVATE_NETWORK
    baremetal_public_network_aggregate: PUBLIC_NETWOR

以前のGitOpsを使用しない通常のフローでは、専門の担当者が関連するAPIを使用し新しいBaremetalの登録などの作業を行っていました。その頃の運用方法では、担当者の作業コストが高いだけではなく、その作業を行う際のどのようにしてレビューを行うのかなどの問題を抱えていました。一方で最近導入されたGitOpsを使用したBaremetal管理手法では、Baremetalの新規追加、削除を含む全ての作業を基本的にすべてGit上で行えるようになっています。Baremetalを新規で追加したい場合はGit上に追加したいBaremetalのハードウェア情報を追加し、PRを使用することにより必要に応じて担当者間でレビューを行うことも可能です。また、Git上でBaremetalの管理が行えるようになったことにより、例えばサーバの故障等でハードウェアパーツの交換が発生した場合に、Mac Address等の変更が発生した場合にもGit上のサーバ情報を書き換えることにより、これらの変更を適用することができます。

BSIPでは、Argo Workflows上の処理でYAMLファイル形式のBaremetal情報を登録(Git Push)してやり、最終的にLINEのサービス開発を行っている社内の開発者の方へBaremetalを提供しています。

BSIP導入後の現在

これらのBSIPが導入された2022年現在、Baremetalの初期セットアップ作業時間は大幅に短縮され、従来2-3日程度かかっていた作業がおおよそサーバ1台あたり1時間程度で行えるようになりました。BSIPを導入する過程でセットアップ内容自体の見直しを行った効果もありますが、作業時間と作業者の負荷ともに大幅に改善がされたと感じています。

また、セットアップ途中にハードウェア起因の問題を引きセットアップが失敗するようなケースでも、Argo Workflows上の処理ログから状況を確認しトラブルシューティングを開始できるようになった為、以前と比べてトラブルシューティングのやりやすさも格段に向上しました。現状ではまだArgo WorkflowsのWorkflow処理を開始するトリガーを作業担当者がWebUI上から手動でトリガーする必要がありますが、今後この部分の自動化にも取り組みさらにもう一段階上の自動化も達成できるのではないかと考えています。

BSIPでArgo Workflowsを採用して感じたこと

結論から言うと今回のBSIPでArgo Workflowsを採用したことは大正解だったかなと感じています。

Kubernetes-Based Workflow EngineとしてのArgo Workflowsの扱いやすさ

まず、Kubernetes-Based Workflow EngineとしてのArgo Workflowsの扱いやすさです。Argo Workflows自体が純粋なコンテナ技術とKubernetesのCRDで作られていることを前述しましたが、これは逆に言うと自分たちの行いたい処理を何らかの形で実装しコンテナイメージにするだけで、あとの一連のワークフロー処理はArgo WorkflowsのManifestを書くだけで完結してしまいます。当然Argo WorkflowsのManifestに対する学習コストはかかってきますが、それさえできれば誰でも自由にかつ比較的簡単にワークフロー処理を実行することができます。ワークフロー処理の流れや設定をすべてArgo Workflowsに委任することにより、我々BSIPの開発者は1つ1つの処理を行っている実装にのみ焦点を当てメンテナンスを行うだけで十分になります。これにより、BSIP自体のメンテナンスがかなり楽になりました。

やるべきことが明確になった

Argo Workflowsを利用したことにより、Baremetal初期セットアップの自動化をやるにあたって、我々が次にやらないといけないことが明確になりました。BSIPではArgo WorkflowsにWorkflowをApplyすれば自動的にBaremetalの初期セットアップを行えるようになりました。なので、更にBaremetalの初期セットアップの自動化を促進していきたいのであれば、Argo WorkflowsにWorkflowをApplyする過程までを、もっと言えばArgo WorkflowsのManifestを作成しAPIに Pushするところまでを行えば良いことになります。現在のBSIPではWorkflowを実行するのに必要なサーバ情報を人の手で作成する必要がありますが、今後ZTP(Zero Touch Provisioning)の仕組みを取り入れるなどしてこの部分の自動化を進めることができればさらにもう1段階上の自動化を行うことができます。という形で我々がやるべきことがかなり明確になったというのはArgo Workflowsを採用したことによる間接的な効果だったかなと感じています。

パフォーマンスチューニング

これはArgo Workflows自体の話になりますが、Argo WorkflowsではWorkflowを実行した際にWorkflow内のステップごとにKubernetesのPodが作成され実行されます。これは今回のBSIPで考えると、一連のWorkflow内に10個のステップが存在し、1000台のBaremetalを一気にセットアップしたいと考えた場合10 Pods(Steps) * 1000 Workflows = 10000 Pods というPodがKubernetesのCluster上に作成されることになります。Kubernetes自体に関しては基本的にスケールアウトで対応可能ですが、Argo Workflows自体のパフォーマンスチューニングになるとそう単純な話ではありません。Argo Workflowsではアーキテクチャ上どうしてもスケールアウトができないコンポーネントが一部存在します。それらのコンポーネントの垂直スケールに必要なパラメーター調整や通常では Etcdに保存しているWorkflow情報のMySQLへのオフロードなど、今回のBSIPで使用したArgo Workflowsでは多くのパラメーター調整や設定の変更を行いました。これらの情報は一般情報としてはまだ十分に出てきてないなというのを感じました。実際今回のBSIPでもかなり泥臭くトライ・アンド・エラーを繰り返してパフォーマンスチューニングを行いました。

Argo Workflows Manifestの学習コスト

Argo Workflowsを利用するには当然そのWorkflow情報などのリソースを定義するManifestをYAMLフォーマットで書く必要がありますが、このManifestを書くための学習コストが高いという話です。Argo Workflows自体できることの幅がかなり広いのがメリットではあるのですが、その反面Manifestの構造が複雑で学習コストは比較的高いと感じました。

まとめ

私が入社して以来携わってきた、LINE のBaremetal初期セットアッププロセスをArgo Workflowsを使って自動化したお話をご紹介しました。後半はArgo Workflows寄りの話になってしまいましたが、Argo Workflows 自体かなり便利なツールで、使い方次第では様々な業務を自動化、効率化できるのではないかと感じています。

今回Baremetalのセットアップ自動化のお話をしましたが、LINE ではサービスの成長に伴う様々なサーバインフラなどの拡大で、これからもさらなる運用の効率化や改善を行っていく必要があります。こんな LINE のインフラに携わってみたいと思われた方がいらっしゃいましたら、是非以下のポジションを御覧ください。

それではここまでお付き合いただきありがとうございました！

LINEでは一緒に働くメンバーを募集しています

LINE株式会社では一緒に働くエンジニアを募集しています！今回の記事に関連した募集ポジションはこちらです、ご応募お待ちしております。

Blog