イベント
金融企業のインフラをプライベートクラウド化した技術面・文化面での体験談
Cloud Operator Days Tokyo 2020 ブレークアウトセッションレポート
2020年8月3日 13:15
クラウドインフラ運用技術者のための年次カンファレンスイベント「Cloud Operator Days Tokyo 2020」が、7月29日～30日にオンライン開催された。
ここでは2日目の7月30日のブレークアウトセッションの模様をレポートする。
佐々木了氏のセッション「OpenStackを導入・1年運用したチームの変化」では、佐々木氏がフリーランスとして参加している金融企業のインフラチームにおいて、OpenStackや自動化などを導入した経験が語られた。
セッションは、前半は技術の話、後半は文化の話という構成で進行した。
Git、Ansible、Dockerの“三種の神器”を積極的に活用
まずは技術の話。この金融企業で2018年度末にOpenStackを導入した。それまで物理サーバーが非常に多く、作りこんだ環境が動いていた。この構成となっていた理由としては、「前からそうしていて慣れていたから」ということや、「外部SIerに依存していて改革意識が薄かった」ことを佐々木氏は挙げた。
従来の環境では、開発チームがインフラチームにサーバーを申請すると、インフラチームがサーバーを1～2カ月で用意するというフローだった。「開発者は必要なリソースをすぐ自由に欲しい。開発者に主権と自由を、ということでプライベートクラウドに移行した」と佐々木氏は語った。
プラットフォームには、ベンダーサポートのために、Red Hat OpenStack Platform v13を採用した。対象環境は開発環境やステージング環境で、本番系はまだだという。
導入にあたっては、インフラチームは人数が少なく、いかに少ない人数で安定的な運用を続けるかを考えた。考えたことは、作業品質の一定化と、作業の再利用性を高めることだ。加えて、「二度あることは百度ある」「人間はミスる」点を考慮した。
そこで、Git、Ansible、Dockerの“三種の神器”を積極的に使うことにした。「あたりまえと思うかもしれないが、意外と世の中あたりまえじゃない」と佐々木氏。
運用作業は原則的にAnsibleでコード化し、そのコードはGitLabで管理する。環境は極力コンテナ化して運用する。
CI/CDも積極的に使い始めた。ツールとしてはGitLabのCI/CD機能を採用。これは、「メンバーが慣れていないので、むやみにツールを増やすべきでない」という判断だという。
さて、OpenStackは定期的にアップデートがあって大変と言われている。それに対する佐々木氏の持論は「（普段）アップデートをしないからアップデートが怖い」ということで、アップデートの経験を積もうというものだ。
そのために、OpenStackの検証系を作って、アップデートはそこで検証することにしたという。検証系のOpenStackはOpenStack上で動くものとした。
Ansibleでコード化した構成も、CI/CDする。これを、検証用OpenStackですべて試行し、問題がなければ実環境に適用することにした。
実績としては、アップデートだけなら3カ月に1回。機能追加やパラメータ変更などはもう少し回数をこなしている。
ただし、基本的に一発で成功はしないか、成功しても不具合が出るという。そこで、Red HatのBugzillaやKnowledgeの事前確認は必須で、未報告の不具合についてはアップストリーム側も調査する。必要があればパッチも自前で作る。
「自分たちで調べるスキル、直せるスキルを身につけないといけない。そのうえでベンダーに頼る」と佐々木氏は説明した。
監視はほぼ自前で実装した。Zabbixから、メトリクスの収集や、全APIのGETのほか、インスタンスの作成と削除を15分に1回実行するなどもしている。
検証系の構成は実環境と可能な限り同じにし、メトリクス収集よりも、ユーザーの利用シーンを模倣することを重視しているという。実例として、デプロイと監視は問題ないのにインスタンスを作れないケースがあって、Horizon（ダッシュボード）だけ問題が出ていたとわかった。そこで対策として、SeleniumによってHorizonからインスタンスを作成・削除する監視アイテムを実行するようにした。
こうして監視アイテムは増え続け、現在は100個以上にのぼるという。
いままで使ったことがない中で、文化をどう変えるか？
後半は文化の話だ。
この事例のインフラチームは、はじめは1人で、いま4人に増えた。社員としてのエンジニアは非常に少なく、SIやフリーランスなどに依存しているという。
社内の文化としても、インフラチームにはGitやInfrastructure as Codeの文化がなく、将来性や効率などを意識していないその場しのぎが多かったとのこと。
佐々木氏は、そうした文化を変えていこうと考え、前述のように「いかに少ない人数で安定的な運用を続けるか」の方策と、三種の神器を取り入れた。
とはいえ、いままで使ったことがない中で、文化をどう変えるかが問題となる。そこで佐々木氏は“とにかく自分が先頭に立って切り開く”ことにした。実績を作ることで説得力が増し、参考にしやすくなり、ゼロからの学習コストを下げることになる。
情報もすべてをオープンにした。ドキュメントも、作成の負担が低いMarkdownとし、心理的負担を下げて気軽にドキュメント化して公開した。
こうして個人の文化をチームの文化にすることにより、「Ansibleのプレイブックを書いた」「コンテナ化した」「GitLabに上げた」という会話が当たり前になった。
さらに、チームの活動を他チームに伝えて、ほかのチームにもひろめる活動もした。開発チームは、任意タイミングで高速で開発リソースが用意されるようになり、コンテナも積極活用するようになった。
ただし、変化への反発も予想される。これまで環境の用意をインフラチームに任せていたのが、開発部が自分でリソースを用意することで、反発があるかもしれないと考えたという。
その対策として佐々木氏は「こうしたことは技術要素よりも精神論」として、開発チームと積極的に仲良くなり、理解するようにした。
「さらに大事なのが、筋を通すこと」として、相手の目の前の不満を表に引っ張り出し、それに対する直接的な解決策を提示するのが重要だと佐々木氏は言う。ただし、それをすべての人に対してするのは難しいため、最大公約数的な不満をみつけて解決策を提示することになるという。
「さらに、もっと開発者に主権を、と考えている」と佐々木氏。考えるべきは、誰のためのインフラなのか、誰のための運用なのか。つまり、開発者のためだ。それを考えると必要なこと見つかってくるという。
最後に、今後の計画も語られた。現在、開発チームもコンテナ化を進めることにヤル気満々だという。ただし、コンテナの数が増えると大変ということで、Kubernetes導入してはどうかという声があるという。「こちらから開発チームにコンテナを押しつけていたらこうなっていなかった」（佐々木氏）
そこで、Kubernetes導入に向けてプロジェクトを推進している。同時に、本番系OpenStack導入を目指した活動も推進中だと佐々木氏は語った。
