こんにちは、ぐるなびのインフラを担当している飯田です。
私の所属するグループでは、ぐるなび全体のサイトインフラの構築や運用を行っています。
私自身は、新卒で入社して今年で四年目となります。現在は、ぐるなび全体の仮想基盤やコンテナ基盤の運用、IaCなどを主に担当しています 。
今回は、我々が開発し提供している社内システムをコンテナ化し、そこでどういう技術に取り組んでいるかという話をしたいと思います。
インフラが提供する社内システムとは
ぐるなびでは、サーバの払い出しやミドルウェアの設定変更などが発生する度にインフラへ依頼し、それに対してインフラが対応するフローをとっています。
このフローだと間接工数が増え、サービスの開発スピードが遅くなるなどの課題がありました。
そのため、開発効率やスピードの向上のため一部のオペレーションに対してGUI化やAPI化を実施し、社内システムとして提供しています。
また、システム化することでオペミスを減らし作業品質の向上をはかっています。
実際に提供しているメニューの一部が以下になります。
- Jenkinsの実行基盤
- Load Balancerからサーバの切り離し
- DDL実行
コンテナ化をした理由
社内システムの一部は、Dockerで開発し、Kubernetes上で稼働させています。 Dockerを選択したことには大きく分けて二つの理由があります。
- 既存の社内システムでの課題解決
- DockerやKubernetesの学習・検証
既存の社内システムで課題の解決
もともと提供していた社内システムがありましたが、モノリシックな構成で、提供するメニューごとの個別要件が満たしづらい点がありました。 また、既存の社内システムに関しては私ともう一人のメンバーで構築運用をしていましたが、オペレーションのセルフサービス化が進むにつれて関係者も増え、リリースサイクルや効率を考えるとDockerでの開発が適していると判断をしました。
DockerやKubernetesの学習・検証
ぐるなびのサイトの一部では、Kubernetes上でサービスを提供しています。Kubernetesは、オンプレミスで提供しているためその運用の専門性はとても高くなっています。
DockerやKubernetesのノウハウやナレッジ、トラブルシューティングをインフラのメンバーが同じレベルで知っておくのはとても難しいです。 ただ、インフラチームが運用しているものなので最低限の知識は全員が知っておくほうがよいと考えています。 いきなり稼働中のサービスを触るのはハードルが高いため社内システムなどサービスレベルの低いところから慣れていくためにはとてもよいタイミングでした。 また、サービスメッシュや可視化などコンテナ基盤を取り巻く技術はサービスに取り入れるため検証の場を作りたかったということがあります。
実際に検証していること
検証内容というよりは、こういうものに取り組んでいますというご紹介になります。
- GitOps
- サービスメッシュ
- Beats
GitOps
現在のぐるなびのコンテナ基盤では、インフラでデプロイツールを作り、GitLab CIと組み合わせてPaaSのような形で提供しています。 日々の運用においては問題がありませんが、最終的なマニフェストが管理されていないことと復旧時に手動で復旧しないといけないという課題がありました。 マニフェストの管理自体は、CI / CDの中に組み込めばいいだけなので難しくはないですが、復旧時に、人がCLIをたたく部分を極力増やしたくないのでより簡単に実現する方法を探りました。
いくつか実現できるものは存在しますが、今回はArgo CDを選びました。
Argo CDは、Kustomizeやhelmへの対応や可視化など、またアプリケーション単位で複数のリポジトリを管理できるところに魅力を感じました。
Argo CD自体は、リポジトリと連携しマニフェストの内容をKubernetes上にデリバリーをする仕組みになっています。
社内システムのデプロイにはArgo CDを導入してみましたが、GUIでの操作も可能なためkubectlに不慣れであっても使えるので扱いやすいと感
じました。
実運用に乗せるとなると監視など考える点が増えるのですぐにデプロイの仕組みをすべてよせることは難しいですが、現在は手動で行っているreplica数の変更など部分的には使っていけるのではないかなと思いました。
サービスメッシュ
サービスメッシュとは、マイクロサービスにおける以下のような課題を解決するための技術です。
- Service Discovery
- Observability
- 認証・認可
etc…
ぐるなびでは多くが密結合となっており、コンテナ化されたサービスから少しずつマイクロサービス化が進められています。 現状、これらの課題が大きく問題視されていませんが、今後マイクロサービス化が進められていくと避けては通れないと考えています。 必要になってから検証を始めるとなると時間も多くかかるため、早いうちからナレッジをためるため社内システムはマイクロサービスで構成しマイクロサービス間の通信はIstioで行うよう構築しました。
Istioの導入によって、トラフィック管理をIstio層に集約できたり、サービス間の認証をアプリケーションから分離できるメリットがありますが、10ms程のオーバーヘッドや登場人物が増えることによって全体的には複雑になりました。
プロダクションで使うとなるとKubernetes同様に専門的なエンジニアが必要になりそうだなと感じました。
Beats
Beatsとは、Elastic社が提供しているデータシッピングプラッ トフォームです。
ぐるなびではログ基盤としてElastic Stackが採用されています。仮想マシンでもKubernetesでもすべてのログはElasticSearchへ保存され、Kibanaで可視化されています。 監視基盤としては、ZabbixやPrometheusでメトリックを収集してGrafanaで可視化をしています。 そのため、あるサービスのレスポンスタイムの劣化からシステムの状態を紐づけるために画面を行き来し、さらにそこから深堀していくと画面を何往復もするなんてこともよくあります。
今回、システムデータをMetricbeatでElasticSearchへ飛ばし、Kibanaで可視化の一元化をしました。 ElasticSearchとPrometheusではアーキテクチャが違うのでどちらが良いかという比較はできませんが、システムログやアプリケーションログ と合わせて分析をする場面では扱いやすいと感じました。
社内システムをコンテナ化してみてよかった点
まずは、コンテナや新しい技術への理解が深まった点です。 今までコンテナに触れてこなかったメンバーも理解が深まりチーム全体のスキルアップができました。 座学ベースでの勉強会も実施しましたが、実際に触らないと理解し辛い部分や時間の経過とともに忘れてしまうことは多くあります。 今回、構築・運用と経験しているのでその点、身につくことが多かったのかなと思います 。
また、開発環境などインフラのメンバーしか利用していない場所ではnamespaceを消したりサービスを落としてみるなど障害対応の練習やナレ ッジを蓄積することができました。
まとめ
我々の目的はサービスの安定稼働ですが、新しい技術にも挑戦していかないとより良いサービスは作れないと考えています。 ただ、誰か一人や少人数だけが挑戦を続けてもあまり意味がなく何かしらの形でチームに還元するかチーム全体として取り組む場面があるとよいのかなと思います。
また、進めていく上で、特に最初のうちはアウトプットやレビューのタイミングを適度に細かく設定することが重要だと思います。 新しい技術の探求はエンジニアとしてのモチベーションにも繋がりますが、稀にサービスに生かせない技術を突き進めてしまうこともあるからです。
今回、紹介させてもらった技術はプロダクションでの利用はできていませんが、今後適した場面があれば利用してみたいと思います。
