うちの島でDevOpsについて語ろうよ！ 「あつまれ どうぶつの森」を舞台にしたDevOpsカンファレンス開催

構築は大変だが見返りは大きい、DevOpsとCI/CD導入のススメ

　2本目に紹介する「The Long Game」（ロングゲーム）は、Moda OperandiのDevOpsリードエンジニア、ジャック・ナイヴズ氏による講演。DevOpsは収益に直結しないとしてプラットフォーム導入をためらう人向けに、必要である理由、DevOpsのメリット、CI/CD構築のポイント、開発者とインフラ運用者の連係を円滑にするための自動化などについて語った。

　「たしかに、DevOpsは利益に直結しないし、より安定したコードを生み出すプラットフォームを開発するにしても、時間と専門知識が必要だ。そこまでして開発するものなのか分からない。そう考える人も多いだろう」。ナイヴズ氏は冒頭でこう切り出した。

「DevOpsは一見すると、利益にならない、時間とコストばかりかかる仕組みに見えてしまう」（ナイヴズ氏）

　実際、DevOpsは新たな文化や概念を取り入れて定着させるプロセスがあり、目に見えた効果を出すにはCI/CDによる構築およびテストの自動化が必要だ。

　「たとえば、エンジニアのひとりが本番環境のデータベースに手動でホットフィックスを適用し、その旨を作業ログに残すことを忘れたとする。その後、別のエンジニアが定期デプロイを実行したところ、不具合が発生。作業ログには何も書かれていないので原因が分からない。結局、そのエンジニアは貴重な業務時間を費やし、必死に原因究明するはめになる。これは、よくある話だと思う。こうしたヒューマンエラーに起因する不具合やダウンタイムは、CI/CDの自動化によって劇的に削減できる。エンジニアも、より生産的な業務に時間を使えるようになるだろう」（ナイヴズ氏）

　ヒューマンエラーは大きなリスクだ。アラートを設定し忘れたせいでサービスが3日間も落ちていることに気付かない、必ずしもすべてのクラウドサービスの設定を把握しているわけではない開発者が設定ミスを犯したせいでインフラ関連のリソースがアクセス制限なしで大公開されたまま数か月が過ぎていた、といった話も残念ながら少なくないとナイヴズ氏は言う。

　よく設計されたDevOpsとCI/CDプラットフォームは優れた安定性や管理性、オブザーバビリティを提供し、結果的にカイゼンのサイクルを爆上げすると力説するナイヴズ氏。「もっとも、10あるプロセスのうちひとつを自動化するだけでは不完全で、やるなら徹底的に取り組む必要がある。大変だけど、得られる恩恵は計り知れない」

　そこで登場するのが、DevOpsエンジニアだ。DevOpsエンジニアの役割は、開発者とインフラ担当者の架け橋となり、双方の煩雑な作業を簡素化して、アジリティに優れた開発とリリースを実践できるよう支援すること。CI/CDの整備も、仕事のひとつだ。

　ナイヴズ氏は、CI/CDプラットフォームの例を一連の処理の流れに沿って紹介した。開発者がコードをGitのブランチにプッシュしたら、その後はCIプロセスが走り、ユニットテストやインテグレーションテストなどが自動実行され、諸々をコンテナイメージにパッケージ化したら、非本番環境へ自動デプロイ。モニタリングおよびアラート、必要に応じてロードバランサーやドメイン名を設定して検証を開始する。

　「テストで問題が発見されなければ、そのまま本番環境に自動デプロイするのがベスト。問題あればアラート通知があるので、都度対処すればいい。それでも怖い場合は、手動またはスケジュール設定などで対応する。これはシステムによって適宜判断するといい」（ナイヴズ氏）

　重要なポイントは、開発者がやるのはコードをプッシュするだけということ。以降のプロセスに関わることはないので、「バグのないコードを書くことにひたすら専念できる」とナイヴズ氏はメリットを挙げる。

開発者がコードをプッシュし、あとはCI/CDが自動実行。ちなみに開発者のイメージモデルをあつ森の博物館館長フータにした理由は「バグ（虫）が大嫌いなキャラクターだから」（ナイヴズ氏）

　インフラ周りで必要な設定は、開発者のニーズを踏まえてDevOpsエンジニアがIaC（Infrastructure as a Code）でデータベースモジュールやRedisモジュールなどのカスタムモジュールを作成。開発者がコードをプッシュした際に自動でインフラ管理レポジトリにドロップされ、CI/CDが適宜判断して本番環境へのデプロイまで持っていくよう設計する。

インフラ周りの設定や構成は、DevOpsエンジニアがモジュールで提供。開発者の負担を軽減する。なお、DevOpsエンジニアのイメージモデルは、フータの妹でしっかり者のリケジョ、フー子だ

　「開発者とDevOpsエンジニアの関係性が悪化するのは、各プロセスの属人性が高いからだ。開発者だって、デプロイができないとかデータベースのプロビジョニングが必要とか、何度もDevOpsエンジニアに問い合わせるのは煩わしいと感じているはずだ。同様に、DevOpsエンジニアも毎回デプロイ済みのコードのトラブルシューティングに奔走させられたり、同じ構成を何度もコピペさせられたりするのはもううんざりだと思っている。いがみ合う関係は終わらせて、より平和で幸せな関係を築きたいと誰もが思っている」（ナイヴズ氏）

　CI/CDで自動化がうまく回せれば、互いに負担の大きいやり取りが大幅に減る。開発者は、ビジネスロジックの実装やバグ解決に集中できるようになり、DevOpsエンジニアはインフラの安全性やオブザーバビリティ、管理性の保証に集中できるようになる。

　「DevOpsの採用やCI/CDの構築は大変な作業だが、それだけの価値はある。自動化できたらなと考えているプロセスがあるのであれば、ぜひ一歩踏み出してチャレンジしてほしい」（ナイヴズ氏）

　本イベントのその他トークは、YouTubeで公開されている。Open Telemetryを活用した分散トレーシングプラットフォームの実装話や、色やUIなどでアクセシビリティを高めるためのヒント、Apache Kafka激推しトーク、カオスエンジニアリング入門編、オブザーバリティプラットフォーム構築苦労話、高校生向けDevOps教育など、盛りだくさんだ。

　「来年も何らかの形で開催できれば」と野望を明かす主催者のパーカー氏は、オンサイトでのイベントも視野に入れている模様。どのような形になるかはこれから検討予定とのこと。もうすでに楽しみだ。

写真撮影で壇上に集まる主催者や講演者たち