Lunch Session (Cybozu): Infrastructure automations pipeline with Kubernetes accepted

Abstract

サイボウズのインフラチームは、今まで様々な手順を自動化してきました。

しかし、インフラの大規模化・複雑化にしたがって、手順ベースの自動化が状態の変化に上手く対応できないことが増えてきました。
そこで、手順ベースではなく、ソースコードで宣言された状態へインフラを収束させる「理想状態への収束」という考え方を導入します。
この発表では、Kubernetes と CloudFormation を組み合わせて、ソースコードで記述した理想状態へ、いかにしてインフラを収束させるか説明します。


サイボウズは自社でデータセンターを運用しており、1000台を超えるサーバーが稼働しています。
大量のサーバーを効率的に扱うために、10万行を超える Python スクリプトで様々なオペレーションを自動化しています。

これまでの自動化の考え方は「手順」ベース、すなわちオペレーターが手動で行っていたコマンドの列を Python コードに置き換えていくことでした。
しかし、手順ベースの自動化には問題があります。
それは状態の変化に脆いということです。

「手順」は差分的です。すなわち、現在の状態と理想状態との差分を記述します。
「手順」をそのまま自動化したシステムは、現在の状態がちょっと変化しただけで破綻してしまいます。

インフラの規模が小さかったころは、「現在の状態」をある程度固定化できました。
しかし、インフラの規模が大きくなると、サーバーは日常的に入れ替わり、メンテナンス(無停止含む)の頻度は高くなり、サービス間の相互作用は理解の範疇を超えるようになってきました。
大規模インフラの「現在の状態」をコントロールすることは、もはや人間業ではありません。

どうやったら大規模にスケールする自動化ができるでしょうか?

「理想状態への収束」という考え方があります。
これは Infrastructure as Code の考え方の一つで、ソースコードで宣言された理想状態とシステムの現在の状態を比較し、差分を自動的に計算してシステムを理想状態へ収束させるという考え方です。
人間は理想状態だけを記述すればいいというのがポイントで、これにより「現在の状態」がヒトの理解を超えるような規模にまでスケールできます。

サイボウズは US 顧客のためのインフラを AWS に移行する予定です。
AWS 移行に際して、今までの辛みを解消するために様々なチャレンジを行っています。

この発表では、Kubernetes と CloudFormation を組み合わせて、ソースコードで記述した理想状態へ、いかにしてインフラを収束させるかの説明を行います。
宣言的に Pod や Service の在り方を記述できる Kubernetes のパワーを感じていただければと思います。

Session Information
Confirmed unconfirmed
Material Level Intermediate
Starts On 9/7/18, 11:40 AM
Room Event Hall
Session Duration Lunch Session
Spoken Language Japanese
Interpretation Unavailable
Slide Language Japanese