[概要編] GCPでVMインスタンスを自動・自律的に構築する仕組み (original) (raw)
はじめに
こんにちは、情報システム部 SRE 橋本です。
今回は我々のチームで運用効率化として構成しているVMインスタンスの自動的・自律的な構築を行う仕組みについて紹介したいと思います。
昨今、クラウド・プラットフォーム上で様々なマネージド・サービスが利用可能になっていますが、10年スパンで継続運用されているシステムでは移行難易度的にそれらのサービスを使うことが難しく、従来構成を維持してVMインスタンスを大量に構築する機会があります。我々の運用システムでもフロントエンドはGKE/コンテナ化が進みつつありますが、DBやKVSなどのデータストアはVMインスタンスで構築しています。
またMySQLなどのデータベースサーバではパフォーマンス等の要件により垂直・水平分割がすすんだ結果、構築台数が多くなるというケースはしばしば発生すると思われます。このようなサーバを構築・運用する場面で以下のような経験をされた方はいないでしょうか？
たとえば
- IaC等で構築自動化しているが自動化→人による作業→自動化→人による作業と合間に人の手による作業が介在してしまっている
- この人の手による作業に依存関係があり、しばしば作業漏れやミスが発生してしまう
- あるいは人の手による作業で作業者にコンテキストスイッチが多々発生してしまい他の仕事に集中できない。
- etc., etc…
構成が複雑になりがちなデータベースサーバでは、複数台のサーバ構築をしているとDBの構築をしているだけで一日が終わってしまったということも目にしたり、筆者自身も経験したことがあります。
マネージドも解ですが
これらを解決するものの一つとして、AWSのRDSやAurora、GCPのCloudSQLやAlloyDBなど、マネージド・サービスを使うことがあります。しかしながら、構成の自由度から独自にVMを構築し運用することはMySQL等に限らずシステム運用においては発生しうるものと思われます。
我々のチームが担当するシステムでも、GCPにおいてMySQLをオンプレミスに構築し運用しています。ここでできる限り構築や運用の負担を軽減するために人手を極力介さずに自律的なサーバー構築が行いたいというモチベーションのもとIaCを活用して運用しているものを今回のシリーズものの投稿で紹介したいと思います。
コンセプトの概要
自律的なサーバ構築を行う仕組みのコンセプトが以下の図のようになります。
先に書いたツライ部分を低減させるために以下の2点の課題解決に主眼をおいています。
- 構築できるまではサーバ側ですべて自律的にプロビジョニングが行われる
- 構築 → テストまでを行い、正常であれ異常であれ完了したら通知をする
先に白状しますと執筆時点では実装し本番環境でおおよそ動いてはいるものの、完全には自動化→通知という仕組みにはなっていません。このコンセプトに向かって実装しているということと、出来上がっている部分で参考にしていただける点が多くあると思うので、一読いただければ幸いです。
この記事の構成
この記事はこのページを含めて以下の4つに分かれています。
- 概要編(このページ)
- VMイメージ継続ビルド編
- サーバ自律構築編
- テスト編
長い記事構成になっていますが、VMの構築・運用が業務上必要で運用負担に悩むインフラに携わるエンジニアの方々の参考になると幸いです。