はじめに
JANOG45 Meeting in Sapporo で、Fastly の土屋さんから「急成長を支えるFastlyスケーラブル・グローバルネットワーク」という発表がありました。
シンプルさを追及した設計や、自動化の話があって大変興味深いものでした。
なかでも私が注目したのが、設定自動化の作業フロー内で「いつ、何を確認するか」です。(該当スライドは P15〜、動画は 22:30〜)
この記事では、Fastly さんの事例とそこから学んだことをまとめます。主に、実機に設定を反映する前の段階にフォーカスします。
なお、当日は残念ながらプログラムに参加できず、資料とアーカイブ動画(2020/03/09 12:00 までの期間限定公開)と togetter を拝見しました。
■ Fastly さんの場合
発表内の設定自動化部分を中心にまとめます。発表の内容をベースにしていますが、若干自己解釈が含まれています。
自動化の背景
- 1年に10拠点くらい増える、数年後に倍になっているかもしれない
- とはいえ、ネットワークエンジニアを倍に増やすわけにはいかない
- スケーラブルにするために自動化
- トポロジーやコンフィギュレーションがシンプル、標準化しやすいので自動化もしやすい
自動化していること
- 1コマンドできるように自動化している
- ピアのトラフィックが輻輳しそうなときの対応
- トランジットのトラフィックが輻輳しそうなときの対応
- ピアやトランジットのメンテナンス時の迂回(ドレイン)
- コンフィギュレーション
Network Configuration Workflow
- 新しくピアを張る設定作業の作業フローの話
- 大まかな工程は、Day0 は作業準備期間、Day1 は作業日当日
【Day0】 作業準備期間
- 作業者が手元で作業情報をアップデートし、Pull Request を出す
- 作業情報例
- どのスイッチ、ポートでどことピアを張るか、IPアドレス設定、BGPのパラメーター
- 作業情報例
- CI テスト が実行される
- システムが確認すること
- バリデーションテスト
- システムが確認すること
- 承認者が Pull Request の内容をレビューして問題が無ければデータストアにマージする
- 人が確認すること
- 設定の意図が正しいこと
- 正しいPOPであること、クラッシュ(既知の不具合?)しないこと
- 人が確認すること
- Ansibly (Ansible の内製ラッパーツール)で Dry-run を実行
- パラメーターファイルをもとにコンフィグを生成
- そのコンフィグを機器に流す、ただし commit しない
- システムが確認すること
- ファイルに問題がないか
- 設定に矛盾がないか
- ちゃんと投入できるコンフィグレーションか
- 実際の機器に(commitせずに)投入することで確認できる
【Day1】 作業日当日
- 準備段階で正しいコンフィグができているので、あとはコマンドを叩いて、実際にピアやキャッシュを設定する
- 設定後はネットワークの正常性(トラフィック変化、意図しないアラートがでていないか、など)を人が確認
■ 自動化において、いつ、何を確認するか
前項で、Fastly さんでの事例をまとめました。次は、そこから学んだことや、今までなんとなく頭の中で考えていたことを書き連ねます。(事例とは直接関係ありません)
観点
何のための確認か
- いつ
- だれ(なにが)が
- 何を確認すれば
- 何を防げるのか
何を確認するか
- 構文
- コンフィグが構文的に正しいこと
- 機械的に判断するのが得意
- 実際の機器に投入して commit 寸前でとめてチェックするのが精度が高い
- 人がそれらしく作ったコンフィグでも実際の機器に投入するとエラーになることがある
- 別途コンフィグの構文チェックができる機器もある(Cumulus + Ansible の例)
- コンフィグ投入で即反映するタイプ(commit がない)機器では難しい
- 独自のロジックを作りこんで、事前にチェックはできる
- ただ、精度はチェックロジックの実装依存になる
- 設計
- 設計が正しいこと
- 人が判断するのが得意
- というより機械が苦手
- 機械的に判断できることは限定的、または相応の作りこみが必要
- 振る舞い
いつ、何をチェックするか(できるか)
想定フロー
以下のようフローを想定します。
方針
基本的には以下のような方針になるのかなと考えています。
- 設計の正しさは、人が確認
- 構文の正しさは、機械(自動化システムやネットワーク機器)が確認
フェーズごとの確認のしやすさ
フェーズ | 主体 | 設計チェック | 構文チェック |
---|---|---|---|
(1) パラメーター・コンフィグ作成 | 人 | 【◯】 設計に集中してパラメーターを作成できる。ただし作成者の思い込みや、環境不備によるミスは気が付きにくい。 | 【△】 作成者の環境依存。ローカルの開発環境で lint 的なものを動かしていれば有効 |
(2) CI | 機械 | 【△】 設計意図をくみ取ったり、ネットワーク全体としての妥当性を判断するのは難しく、作り込みが必要。コンフィグの場合は、予めパースする必要がある | 【◯】 スキーマチェック。コンフィグの場合は、予めパースする必要がある |
(3) レビュー | 人 | 【◯】 作成者の思い込みよるミスを防ぎやすい | 【△】 机上チェックになりがちで難しい |
(4) Dry-run | 機械 | 【×】 ネットワーク機器自身に設計意図は判断できない | 【◯】 機器が実際に解釈した結果を得られる |
補足
上記でいう「パラメーター」は、設定値を構造化データフォーマットで定義したものを指します。機器に投入できるコンフィグを生成する元ネタになります。
interfaces: - name: GigabitEthernet1/0/1 description: hogehoge enalbed: true
一方の「コンフィグ」とは機器に投入できるコンフィグそのものを示します。
interface GigabitEthernet1/0/1 description hogehoge no shutdown
さいごに
1つの事例をきっかけにして、いつ、何を確認するかをまとめました。
うまく整理、言語化できていないところもあるかと思いますので、お気づきの点があれば@akira6592 までコメントいただければ幸いです。
これを書いている時に、人が得意なこと・苦手なこと、機械が得意なこと・苦手なことを少し深堀りしたくなったので、まとめたら別途記事を書きます。
参考
www.intentionet.com tekunabe.hatenablog.jp