なぜ開発環境を共有フォルダ→VM→コンテナ、k8sとアップデートしていったのか――八楽における開発、運用改善の取り組みとこれから：多言語、多国籍、多拠点チームの開発環境と働き方

AI自動翻訳プラットフォーム「ヤラクゼン」を企画、開発、運用している八楽は、コンテナやKubernetesを活用したクラウドネイティブな開発、運用スタイルを実現している。現在活用しているコンテナやKubernetesにどのようなメリットを感じているのか、多拠点チームで開発生産性を高めるためにどのような取り組みをしているのかを交えて紹介する。

[Jonas Rydenhag（ヨナス・リィデンハグ），八楽]

　筆者の私が取締役 CTO（最高技術責任者）を務める八楽は、AI自動翻訳プラットフォーム「ヤラクゼン」の企画、開発、運用を通じて、翻訳業務の効率化と翻訳品質の向上、翻訳チームのナレッジ共有を支援しています。ヤラクゼンはソニーや帝人、コニカミノルタなどの大手企業を含め、延べ1000社以上に導入されています。

　2009年の設立以降、開発メンバーの数は年々増加しています。新型コロナウイルス感染症（COVID-19）の拡大以前からテレワークが主体で、米国、ドイツ、ブラジル、インドなどの海外をはじめ、国内（東京、大阪、奈良、高知、その他）から、場所や時間にとらわれずメンバーが働いています。日本の会社ではありますが、私を含め開発メンバーは9割が外国人で、日本人のメンバーはほとんどいません。同じ場所、同じ時間で仕事をしないこともあり、開発環境やデプロイプロセスに多くの苦労や課題がありました。

　本記事では、弊社における開発環境の変化を振り返りつつ、昨今注目を集めるコンテナ、Kubernetes（k8s）、Jenkinsなどを利用した自動化、効率化をどう推進しているのか、テレワークにおける時差などの問題をどう乗り越えているのか紹介します。

以前の開発環境において当時抱えていた問題、課題

　以前の開発環境は、共有サーバに開発者専用のフォルダがあり、そのサーバにインストールされているデータベース（DB）やその他のバッキングサービスを開発者間で共有していました。そして、変更したファイルをサーバ上の専用フォルダに自動的に同期させるようIDE（統合開発環境）を設定していました。

　当時はデータのアップロード中に何かが破損して、サーバとローカルファイルで同期が取れなくなることも複数ありました。またDBに関する問題への対処や、テーブルの変更作業をする場合、サーバ管理者がログインして解決するしかありませんでした。開発者はサーバ管理者の手が空くまで、問題が解決されるのを待たなければならないことが多々あったのです。

　これらの問題を解決するために、各開発者のPCに仮想マシン（VM）をインストールして利用するようにしました。

　これにより多くの課題は解決しましたが、仮想マシンの動作は非常に重く、新しい開発メンバーのためにVM環境をセットアップするのに毎回非常に長い時間がかかっていました。デプロイプロセスのどこかで問題が発生したとき、サーバ管理者が開発メンバーのPCの設定まで踏み込んで解決しなければならないということもよく起こりました。

　開発者ごとに異なるブランチで作業していたため、フレームワークごとの言語のバージョンアップデートも非常に面倒でした。特にサービスのアップグレードに携わる開発メンバーは、プロジェクトやブランチを切り替えるたびに、言語のバージョンをダウングレードする作業を挟む必要がありました。

　そこで取り組んだのが、開発環境のコンテナ化です。コンテナ化はVM環境におけるほとんどの問題の解決に貢献しました。各開発者が自身のPCでコンテナを実行し、問題があればコンテナイメージに変更を加え、その変更を各開発者のローカルに簡単に適用できるようになったのです。

　開発者がアップグレードの作業をしながら言語バージョンを切り替えるのもスムーズになりました。開発環境用のイメージは本番環境用のイメージとほぼ変わらないため、開発者はデプロイ後にローカルで変更した内容が壊れることなくサーバに反映されていることを容易に確認できます。

　以前は、依存関係のアップグレードに多くの手作業が必要だったためちゅうちょしてしまうことが多く、セキュリティパッチのインストールでさえ少し面倒に感じていました。現在は開発者にアップグレードはできるだけ早く対応するよう推奨しています。

コンテナ、Kubernetes、Jenkinsなどの仕組みは開発にどう貢献しているのか

　八楽は現在、コンテナ、Kubernetes、Jenkinsによるテスト自動化の仕組みを構築し、本番環境で運用しています。それぞれの技術要素がどのようなメリットを持ち、どのような課題の解決に役立っているのか深掘りしていきます。

コンテナ

　前述したようにコンテナを利用することで、これまで抱えていた開発に関わる問題をほぼ解決できました。コンテナでは、開発環境と本番環境に大きな差はありません。コンテナを導入する以前は、開発者の環境で言語のバージョンを更新し、次に新しい言語バージョンが本番環境に適用されるまで、新旧両方のバージョンをサポートしているテストサーバを利用。リリース日は、サーバを更新するために本番環境で長いダウンタイムが必要でした。コンテナを導入することで、最新の言語バージョンとフレームワークのバージョンを維持することが、コードベースの変更と同等に容易になりました。

　コンテナを利用すれば、テストサーバや本番サーバに依存関係を手動でインストールする必要はありません。開発者がコンテナイメージに追加するだけで、他の全環境においてリリース時に自動的に更新されます。これにより、サーバ管理者の時間とコストの大幅な削減が可能となりました。

　コンテナ内のプロセスのトラッキングや分析も、1つのサーバ内で複数のサービスが混在していたときに比べはるかに簡単です。以前はサーバが停止、またはクラッシュした場合、どのサービスが原因でダウンしたのかが非常に分かりにくく判明が困難でした。

　新しいコンテナを起動するために新しいサーバに依存関係をインストールする必要がないため、水平方向のスケーリングも瞬時に実行可能です。

テスト自動化

　テストは、既存のコードを変更したり拡張したりする際に重要なセーフティーネットとして機能します。われわれは長年にわたり、新しい機能を搭載するたびにテストコードを書いてきました。つまり、われわれのコードの大部分はテストコードでカバーできているということです。テストカバレッジが高ければ、開発者はアプリケーションを変更する際に、何かが破損することを心配する必要はありません。テストに合格すれば、ユーザーに公開してもアプリケーションは正常に機能するためです。

　ただ、テストコードの数が多いので、コードの実行には時間がかかります。そこでテストを自動化できれば、開発者は現在作業している機能の変更とテストの作成に集中できます。そして、開発したコードをプッシュしたら、プルリクエストを送る前にJenkinsが自動的に既存のテストを全て実行します。新しいコードにより何かが破損した場合、開発者に通知され、コード修正に向けて取り組むことができます。

CI/CD（継続的インテグレーション／継続的デリバリー）

　現在の開発パイプラインを構築するまでは、常にたくさんの手作業が発生していました。リリース前には、各開発者のコード（ブランチ）を一つずつリリースブランチにマージする必要があったため、たいていの場合マージエラーが多発し、リリースブランチの準備だけで丸一日かかっていました。リリース当日は、全てのサーバをオフラインにし、最新のコードを実行するために手動でアップデートする必要がありました。

　現在、開発者によるコードの変更は、コードレビューが終わるとすぐにマージされ、その後すぐ自動的にテストされます。リリース日になれば、開発ブランチは本番ブランチにマージされ、自動的にリリースされる仕組みとなっています。

　普段はリリース前に新機能の受け入れテストを実施してユーザーに新機能を説明するメールを送っていますが、技術的な話に限って言うと、どの時点でも簡単にリリースができます。

Kubernetes

　アプリケーションのコンテナ化は実現していましたが、アップデートの展開やサービスの運用部分をもっと便利にしたいという思いも生まれました。Docker Swarmも検討しましたが、当時はまだ新しいプロジェクトということもあり、多くのコンテナやバッキングサービスを管理するには多少の制限があることも分かりました。Kubernetesのプレゼンテーションビデオを見たとき、とても柔軟でありながら、その中核となる機能が分かりやすいと感じ、興味を持ちました。

　Kubernetesを利用すれば、時間外にサーバやサービスがクラッシュしても十分なアップタイムを確保できる、つまりアプリケーション自体は稼働し続けます。これにより、多数のユーザーが利用するアプリケーションの運営にかかるストレスが解消されます。

　Kubernetesを使い始めてから、水平オートスケーリングもできるようになりました。これにより、アクティビティーの少ない時間帯にかかるコストを削減し、アクティビティーの多い時間帯にはオートスケーリングを通じてアプリケーションのパフォーマンスを確保できます。

　Kubernetesを監視するのに、PrometheusとGrafanaを組み合わせて使うのも非常に便利です。そのため、全てのサービスのパフォーマンスを追跡できるグラフ付きのダッシュボードを複数用意し、サービスが正常に動作していない場合は警告を表示するようにしています。

時差や距離がある開発チームにおける生産性向上の取り組み

　八楽には日本だけでなく、米国、ドイツ、ブラジル、インドなど海外で働いているメンバーがいて、時差のある海外と日本で連携しながら開発を進めています。日々の会話はほとんどSlackで行われます。Slackによるコミュニケーションは相手の作業の邪魔をすることなく、気軽に声を掛けることができます。別のタイムゾーンにいる人も、自分宛てのメッセージだけでなく、自分が作業をしていなかった間に他の人がどのような作業や議論をしていたのか、全て把握できます。

　またコミットメッセージにも力を入れています。開発者がコードを変更する際に、その動機や考え方をコミットメッセージに入力させるルールを設けています。具体的なコミットメッセージを入れるルールを作ったことで、他の開発者のコードを拡張する際に、その開発者に連絡を取り返事をもらえるまで作業を中断せざるを得ないということがなくなりました。

コンテナ、Kubernetesはゴールではない、開発環境のこれから

　コンテナやKubernetesなどいわゆるクラウドネイティブと呼ばれるような取り組みを推進してきましたが、lintの自動化やコードスタイルチェックの仕組みなど、まだまだ課題があると感じています。

　コードスタイルガイドを共有して、開発者全員がガイドに従うようにしていても、ミスは当然起こります。コードレビュー担当者が手動でコードスタイルを確認する必要がないように自動チェックができる体制を作ろうとしているところです。

　また全てのサービスでログを収集していますが、ログを整理できる良い仕組みが今のところ見つかっていません。開発者がバグを修正する必要があるとき、あるいはログから何かを調べたいときには該当のログを見つけるのに時間がかかることがあります。一元的にログを収集、管理してログ同士の関連を分析するソフトウェアの導入も計画しています。

　デプロイプロセスの自動化も実現していますが、自動化に関連するコードの更新は専門知識が必要です。チーム内の開発者にそうした専門知識を持つ人が限られているため、コードをもっとシンプルにして、DevOpsの経験が浅い開発者が自律的にデプロイ自動化の取り組みに参加できるようにしていきたいと考えています。八楽におけるコンテナやKubernetesなどの取り組みが、少しでも参考になれば幸いです。