はじめまして。インフラを担当している湯原です。私たちのグループではぐるなびが提供しているほぼ全てのサービスのインフラ構築と運用を行なっています。日々Dev（開発者）とOps（私たちインフラ担当者）が一体となり熱い議論を交わしながら、さまざまなサービスの開発からリリース・運用を手がけています。
今回、日本国内ではまだ事例の少ないコンテナ技術を使ったシステムを本番サービスでリリースしましたので、コンテナ管理ツール導入の経緯や、ツールを使った実際の流れをご紹介したいと思います。
※該当サービスではRancherというコンテナの管理ツールを使っておりRancher社主催のイベントでもご紹介させて頂きました。こちらでも詳しく触れられております。
Rancher導入プロジェクトの概要
経緯
ぐるなびでは、開発・テスト・本番の3つの環境を用意しています。開発環境では、自由に仮想マシンやネットワーク環境が使えるようになっています。普段の開発プロセスは、開発環境で開発したアプリをテスト環境・本番環境という順にデプロイするというものです。しかし今回のプロジェクトでは開発チームがDockerを使っていたこともあり、キックオフの段階からコンテナを使っていこうというモチベーションでスタートしました。
なぜなら、開発者のマシンでDockerを立ち上げ、そこで開発・ビルドされたコンテナイメージを、そのままテスト環境・本番環境へデプロイすることによって、環境構築にかかる時間を圧縮しデリバリースピードを向上させたいという思いがあったためです。また、Dockerを採用することでコンテナのポータビリティを活用し、Blue/Greenデプロイの手法を用いたより安全なリリースを実現できるのではという思いもありました。
特に、「安全なリリース」という点においては、大きなチャレンジ。ぐるなびではテスト環境では問題が見つからなくても、本番にリリースされると環境やデータの差異によってアプリケーションに不具合が生じてしまうことが少なからず発生していました。これを払拭しようと思います。
コンテナ管理ツールの役割
コンテナを使って本番リリースをするためにはコンテナの管理方法とデプロイ方法を考えなければいけません。ローカルのDocker環境であればdockerコマンドをCLIから操作していきますが、複数のDockerホストで構成された本番環境では各Dockerホストにログインしdockerコマンドを操作するような管理方法は現実的ではありません。かといってKubernetes（以下k8s）などを使いこなすのもなかなかハードルが高そうです。
また本番環境でのDocker利用にあたっては、可用性を持たせるためにDockerホストのクラスタリングや、クラスター化されたホストに対するDockerイメージのデプロイを行う必要があります。
これらをどのように実装しようか、と考えたときに出会ったのがコンテナ管理ツールのRancher。RancherではDockerホストの管理やコンテナのデプロイをGUIから簡単に操作できますし、JenkinsやGitLabなどと連携しCI/CDなどのパイプラインも簡単に組むことができます。
Rancherを使ってできること
Rancherはk8sやRancher社が開発したオーケストレーターであるCattleを使って手軽にクラスターを構築することができます。ぐるなびではまだ利用していませんがオンプレミスの環境だけでなく、Amazon EC2やMicrosoft Azureなど様々なパブリッククラウド上にも環境を構築することができます。次期バージョンでは、GoogleのGKEやAmazonのEKSなどのk8sクラスターをRancherで管理できる統合的なプラットフォームへとアップデートされることがアナウンスされています。
そしてこのクラスターに対してコンテナをデプロイしたり、ロールバックすることも可能です。ロードバランサ機能と連動してオートスケールを実現することもでき、数秒でコンテナがスケールアウトされていく様はかなりの衝撃です。
Rancherの機能のひとつ「カタログ」が使えるのも嬉しいところです。あらかじめ用意されたコンテナのテンプレートをカタログとして登録しておくことで、誰でも簡単にコンテナの管理やシステム構築ができるようになるのです。
コミュニティなどを通して多くのカタログが共有されているので誰でも自由に使うことができますし、組織の中で独自のカタログを作成して共有することも可能です。今回のサービスリリースにあたってはPrometheusのカタログを使ってコンテナの監視に活用しています。
一方でRancherで用意されていない機能もあります。具体例を2つ紹介します。
1つ目はコンテナレジストリを独自で用意するか、またはカタログから作成する必要があります。2つ目はイメージのデプロイに関してもRancherのGUIからできますが、継続的インテグレーション(CI)/継続的デリバリー(CD)を実現するようなワークフロー機能はないため別途用意する必要があります。逆に言えば開発者が使い慣れたツールを使ってワークフローを作り込むことができるわけです。ぐるなびではJenkinsを使ったデプロイが開発者の中で広まっていたため、使い慣れたJenkinsをそのまま使えた事も導入のしやすさに繋がった点だと考えています。
ぐるなびに導入した開発・リリースの流れ
実際のリリースにかかわる構成の大まかな図です。Webコンテナ（RancherではStackと呼ばれる複数のコンテナ群で構成されます）のA系とB系が予め用意されており片側のみ本番アクティブな状態です。
リリースに際しては、アクティブでない系統のStackに対してデプロイを行います。
デプロイ完了後、動作確認を行います。ここではリリース前でありながら実際の本番環境での試験が可能。テスト環境では行えないような実際のデータで動作確認できます。
テストをパスすると、パイプラインの最終ステージ。RancherのLBを切り替えることでBlue/Greenデプロイが完了します。
仮にリリース後に何らかの不具合が発生してしまった場合は、再びRancherのLBを切り戻すことで素早くロールバックを行うことができます。
このようにRancherを活用したBlue/Greenデプロイによって、これまで以上に安全なリリースを実現することができるようになりました。
コンテナを選択する上で大切なこと
今回のリリースをきっかけに、「マイクロサービス」に取り組む多くの方々とお話をさせていただく機会がありました。マイクロサービスは実際のところ国内における事例も少なく技術も急速に変化しているため、まだまだ試行錯誤の段階のように感じます。
コンテナはマイクロサービスを実現する手段の一つではありますが、コンテナを導入すれば全てが解決されるという訳ではありません。今回は
デリバリースピードの向上
Blue/Greenデプロイによる安全なリリース
という明確な目的を持っていたことでコンテナを選択しました。しかし、必ずしもコンテナが最適解ではないという点には注意が必要です。何を解決するのか？というゴールをきっちり決めておくことがとても大切になります。
コンテナ導入によるメリット
Rancher導入前のぐるなびでのアプリケーション開発では、GitLabにプッシュしたソースコードのテストや連携確認を行うためには、指定の言語やバージョン、必要なモジュールなどがセットアップされたサーバを準備しなければなりませんでした。
こういった開発者とインフラ担当者が密に連携しながら開発プロセスを回していたものが、コンテナの導入によってプッシュされたソースコードがビルドされたコンテナを、Rancherを通じて開発環境にデプロイすることで、開発からテスト・リリースまでの一連のサイクルをシンプルに回せるように変わってきました。まさにDevOpsが実現されてきた形になります。
今後の展開
コンテナはポータビリティが高いため、テレビ放送などによる急激なアクセス増加時でもオートスケールによってサイトを落とすことなく安定してサービスを維持することができます。また、Rancherによってオンプレミスやパブリッククラウドなどロケーションを問わずワークロードを選択でき、価格や種類に応じて使い分けることが可能となります。
私達インフラグループではサービスの安定稼動のため常に仕組みの改善や新しい技術の導入を行っています。コンテナ界隈の目まぐるしい動きをキャッチアップし幅広く挑戦し続けられることは、ぐるなびのインフラならではだと思います。今後もより良いインフラを目指して取り組んでいきます。
お知らせ
ぐるなびでは一緒に働く仲間を募集しています。
