15分でできる (ようになる) 環境構築

こんにちは、ChatGPT です。
嘘です。ただの情シス部員のホシイです。

エンジニア組織がある多くの会社ではよくあるように、弊社でも、エンジニアが自身の業務に係る内容を社内向けに発表する機会が様々あります。その中でもおおきなものが昨年の末に企画されておりまして、その場でお話をさせていただける貴重なひと枠をいただきました。ひとり一枠 50 分 (うち 10 分は質疑応答) となかなか長めのものでしたので準備がちょっと心配だったりもしたのですが、なんとか完走することができました。

今日は、その場でお話ししたことをダイジェストでお送りしたいと思います。ぜんぶだと 70 スライドほどありちょっと長いのと、社内限定情報を削除したり、記事としての体裁に合うようにすこし編集を加えたりしています。
また、社内版では “弊社らしい” 非常に素敵な背景がついていたのですが、残念ながらこの場では様々大人の事情により、白一色背景の味気ないスライドでお送りします。(イラストはよく いらすとや さんのものを使用させていただいております。ありがとうございます)

※ 内容は一部のシステムでの一例であり、全社での取り組み・ポリシーではありません。

タイトルは、“15分でできるサーバー環境構築” としました。
テスト環境や QA 環境など、サーバー環境構築ってしんどいものですよねという課題の確認から、近年のさまざまな仕組みの活用によりこれくらい楽にできる例がありますよというストーリーです。15 分というのは結果それくらいでできるようになりましたという数値なのですが、これは 15 分くらいの作業をがんばることでできるということではなく、実際にはコマンド (helm install) を打ってしまえば作業的には完了で、あとは待つだけです。
今回 VM host ベースの環境から Kubernetes で動作するものに変えたのですが、アプリケーションの依存関係がじゃっかん複雑なため、環境構築完了までは Kubernetes の reconciliation を待つだけであるとはいえ、これが 15 分くらいかかるのです。

必要性が上がっている理由として、単に環境を増やしたいというモチベーション以外にも複数の事情があり、またその重要性が増してきています。

さまざまな現場がありますが、インフラ担当チームがわかれている現場ではこのような景色感になっていることが多いのではないでしょうか。開発チームからは環境構築の様子や手法などは認識せず、インフラチームにおまかせしている状態です。開発チームとしてはおねがいするだけなので楽な状態ですが、インフラチームは開発チームの要件をしっかり把握する必要があり、負担が高そうです。

そこに対して IaC を取り入れ、開発チーム主体にしてしまおうという図式です。物理サーバーをデータセンターで扱うインフラでは難しいことですが、クラウドや仮想環境を整備することで容易になります。ただし、すべてを開発チームで完結するのはかんたんではありません。引き続きインフラ担当チームと分担をしていく体制が望ましいでしょう。ネットワークやストレージ、データベースのような領域は一般的に開発チームのスキルセットでは不十分なことが多く、本番環境のみならず外部連携が必要なテスト環境などでも課題が残ることが多いです。

わたしは IaC するなら “3 環境以上はいくつでもおなじ” という感覚でやるべきと思っており、それを伝えるべく示したイメージです。

環境を気軽に増やすにあたりこれが非常に重要なポイントです。環境ごとに差分があるとそれが新しい環境構築の障害になります。たとえばこの環境にはこの機能が無い、この環境では DB の数・種類が違う、またこの環境ではアプリケーションバージョンが違う… 等々です。こういった差を極力小さくしていくことにより、環境を増やすことが楽になりますし、環境によって差がないので動作を見る・利用するときにも誤解がうまれることが少なくなります。

ここに関しては具体的な例をとっていくつか掘り下げた話をしたのですが、ここでは割愛させていただきます。またの機会に別の記事ででもご紹介できたら幸いです。

またすこし観点が変わりますが、自前実装部分の存在が、仕組みの載せ替えの障害になることがあります。OSS や公開された仕様に乗っていると、それを活用した別の OSS が利用できたりして、結果的に工数削減ができることがあります。逆に自前実装からそれを解決するにはまたそのための自前実装の追加が必要になって… というパターンにハマっていきがちです。

今回お話しした例では、実はまだまだ本番環境どころか QA 環境の置き換えもできていません。それに至るまでにはまだここに書いたような作業が必要で、道は長いです… という締めになっています。
インフラの置き換えはアプリケーションの機能追加のようなものと違い、どこに問題が起きるのかがわかりにくいです。広範囲で繰り返し、小さな工数でテストを繰り返すことができるように準備が必要です。また、ガラッと変わるインフラには運用の知見溜めにまとまった期間が必要になります。多くのことが一度に起こって対応の手がまわらないといったことがないように、部分的な移行が段階的にできるような準備もしたいところです。

まとめ

物理的に集まってではなくオンラインでのプレゼンではありましたが、ふだんの業務について、たくさんのかたに聞いていただき、とてもよい経験をさせていただきました。ふだんの業務では直接の関わりがあまりないかたも多く・広く参加いただき、非常に貴重な機会でした。ぱっと見たところエンジニア職以外の方も多くいらっしゃっており、少しでもこういった取り組みについて知っていただけたらうれしいなと思いました。今後社内でもよりいっそう効率的なインフラ活用が進むよう、いろいろと提案を続けていきたいと思います。

さて、あいさつでは ChatGPT さんの名を騙ってしまいましたが、実際にはどのような答えがもらえるでしょうか。聞いてみました。

さすがの考察です。われわれも負けないように精進を続けないといけませんね… それでは！