KubernetesとIstioを利用したmemesanのインフラについて

はじめに

Crunchtimer Advent Calendar 2020 10日目の記事になります（すこし出すの遅れてしまって申し訳ないです）

https://qiita.com/advent-calendar/2020/crunchtimer

この記事では自社プロダクトmemesanのインフラについて紹介します。

インフラ構成

10月から1ヶ月弱かけてmemesanではGCP上にKubernetesクラスタ（GKE）を構築しました。社内検証フェーズなので今のところ、Staging環境のみを構築しています。インフラ構成図は以下の通りです。現在は分散トランザクションやN+1といった問題が起こりそうなので、モノリシックデータベースなアーキテクチャになっていますが、パフォーマンスによってデータベースも分離したいとこではあります。

Kubernetesの選定

memesanはセルフオーダーアプリです。コア機能が充実してくると、次に飲食業務に関する周辺サービスの展開がしたいと考える可能性もあるでしょう。サービスを展開していく際に、モノリスなアプリケーションの中に機能を追加していくと運用・保守にコストが増えることは想像できます。この点に関して、それぞれのアプリケーションは疎結合であるほうがいいというのは、近年のクラウドネイティブな文脈ではよく出てきますよね。そういった基本的な考え方やIaCを実践することも考え、Kubernetesを選定しました。また、Kubernetesはドキュメントや参考書も多いので、技術的には難しいですが入門のハードルはそこまで高くないかなと感じています。最近だと頻繁に勉強会などもあるので参加すると最新の情報が手に入りやすいかなと思います。

Kubernetes完全ガイド第2版 - インプレスブックス

青山真也（あおやままさや）株式会社サイバーエージェントAI 事業本部2016 年入社。OpenStack を使ったプライベートクラウドやGKE 互換なコンテナプラットフォームをゼロから構築。CyberAgent ではKubernetes/CloudNative 領域のDeveloper Experts としても従事。国内カンファレンスでのKeynoteや海外カンファレンス等、登壇経験多数。世界で2 番目にKubernetes の認定資格を取得。著書に『Kubernetes 完全ガイド』『みんなのDoc

https://book.impress.co.jp/books/1119101148

Kubernetes Meetup Tokyo

Kubernetes Meetup Tokyo は強力なコンテナオーケストレーションツールである Kubernetes について詳しく聞く会です！ ## コミュニケーション Slack に参加してください！ Kubernetes Slack のアカウントを持っていなければ、ここからサインアップできます。 ## 過去の開催過去の開催で配信した録画は、YouTube『Kubernetes Meetup Tokyo チャンネル』で公開しています。 * https://www.youtube.com/c/Kub

https://k8sjp.connpass.com/

Istioの選定

Istioは簡単に言うとマイクロサービスアーキテクチャ向けにサービスメッシュを提供するOSSです。Istioに関してはアプリケーションとアプリの通信のプロトコルでgRPCを使っている関係で選定しました。というのも、インフラ構成図の中でProxyというVirtual Serviceがあると思うのですが、これはgRPCで「AメソッドだったらCustomer, BメソッドだったらProvider」のようにAPI Gatewayのように機能しています。インフラを構築する前から使っているローカル環境ではこの機能をEnvoyで実装していました。Envoyを内部実装で使用しているIstioであれば、もともとのローカルのEnvoy Proxyの機能をIstioで吸収することもできるし、可観測性（オブザーバビリティ）を向上させていくことを考えたときや、マイクロサービスとして展開していくことを考えた時に、Staging環境やProduction環境ではIstioを使うほうがいいと感じたので採用しました。

オーバーエンジニアリングではないかという疑問も沸きそうですが、まだ本番稼働していないうちから試すことができる今のタイミングで採用し、運用の知見を貯める期間も長く確保することができます。

工夫点

GitOps

以前、AWS上に構築した別のサービスでGitOpsを実現しようとしたことがありました。結果として工数の関係やベンダーロックインによってできなかったのですが、今回のmemesanでは実現したいなと思っていました。また、CDツールは採用事例の多いArgoCDを採用しました。ArgoCDはKustomizeでCRDやマニフェストを展開できるので、開発中に環境を何度も作り直しましたがその点で楽でした。

Node Port + Cloud Flare Sync

StagingでCloud Load Balancingを使用すると費用が嵩むので、一旦はIstio Ingress Gatewayをtype NodePortで起動して対応しました。DNSの解決はCloud Flare Syncを使用しました。さすがにProduction環境ではLBを使いたいので、それまでの対応になります。

今後について

まだ、ローカルのminikubeで実験したものの延長線なので、実際にProduction環境で稼働させるためには性能試験や可観測性といったようにやるべきことは多いです。直近であればSecretをSeald Secretに置き換えたり、NamespaceがstagingのPodに対して、preemptibleなマシンで立てているStaging用のNode Poolを使うようにNode Affinityを設定したりしないといけないです。ですが今のところ、Kubernetesの知見があまり社内で貯まっていないので、定期的に勉強会などをして対応できる人を増やしていきたいと考えています。