Photo by Niclas Lundin on unsplash

サービスの急成長に負けないスピードでリリースし続けるKubernetesマイクロサービス

この記事は Kubernetes3 Advent Calendar 2018 4日目の記事です。

お前誰よ; 普段はHotspringというスタートアップで共同創業者エンジニアとしてズボラ旅という旅行サービスを作っています。LINEで旅行の相談ができて、そのまま予約もできるというサービスです。最近は副業への理解を深めるために前職のhey(在籍していたのは経営統合前のコイニー)で副業もしています。簡単にSNS上で物を売れるsoiというプロダクトが最近でました。

KubernetesでマイクロサービスをgRPCでつないでいる。「変なことはしない」を個人的なモットーに、なるべく基本に忠実に、ベーシックな要素を組み合わせてつくっている。考えたことの整理も兼ねて、ここまでの開発の道のりを整理する。個人的にはKubernetesの運用ってマッチョな思想でゴリゴリやっていく、少し近づきにくいイメージがあるのだけど、そうでなくてもサービスの急成長に負けないリリース速度でマイクロサービスを運用するというのを示す。わかっていて突っ込んだアンチパターンも後からわかったものもたくさんあるので、もし詳しい方や気になるかたがいましたらお茶でもしましょう。もしよかったら直してください。

バックエンドの構成

雑な図

前述したズボラ旅のバックエンドを7月~11月ずっと開発していて、作っているマイクロサービスたちは、application-service, user-service, payment-service, chat-backendの4つ。application-serviceは旅行の申し込みを取り扱う。chat-backendはLINE APIからのWebhookリクエスト(ユーザーの発言などが含まれている)を受け取ってDBに保存し、たまにbotのようにreplyを返す。user-serviceはその名の通りユーザー情報を取り扱う。payment-serviceは外部の決済代行会社などとやりとりして決済に関する情報を取り扱う。application-serviceがuser-serviceとpayment-serviceを参照する関係にある。chat-backendもapplication-serviceやuser-serviceを参照する。バックエンドのサービスたちはgRPCでやりとりしている。これまでの経緯を整理する。

2018年7月半ば

以前書いた記事についたコメントや知り合いの意見を参考にバックエンドを作り始める。このときはまだズボラ旅のユーザーとのやりとりはLINE@についてくる管理画面を使っていたし、旅行の申し込みはGoogle Formで受けていたし、ユーザーへの請求は前職で作っていた関係で隅々まで知っているコイニーペイジだったし、ユーザーの管理はGoogle Spreadsheetだった。つまり運用しているバックエンドアプリがまったくない状況だった。リリースから1ヶ月がたって、LINE@の管理画面はかたまるし、スプレッドシートのユーザーリストもGoogle Formも破綻しかけていた。せめて申し込みに関連するGoogle Formとコイニーペイジの発行の手間を削減すべく申し込みページをつくりはじめる。LINE@の管理画面・ユーザーリスト運用問題は同僚のもう1人のエンジニアに全部まかせて分担した。全部1人でやるのが絶対に1番早い。開発言語などをきめる。フロントはVue.jsとした。データはちゃんとRDBでとっておきたいのでバックエンドもつくる。バックエンドは、Railsだと瞬間風速的にスピードはでるけど、プロダクトもどんどん変わっていくし人も増やしたいし、このままRailsお得意のモノリスを目指していくと半年後には破綻する。コンテナイメージも大きくなる。1人でやるのにJavaはtoo muchだ。Golangはほとんど書いたことがないけどやたらとスッと手になじむ。なるべくリリースごとに設計しなおしてつくっていきたいし、Golangで小さく作っていくことにする。

2018年8月

申し込みページがリリースされて対応コストがだいぶ減った。同僚エンジニアが自社開発のチャットアプリをリリースしてLINE@の管理画面から移行して、こちらも対応にかかる時間がだいぶ減った。ここでユーザー管理にチャットと申し込みページをつなげたいのでuser-serviceをつくることにした。Dockerfileもk8sのマニフェストファイルもコピペでだいたいなんとかなるはず。同僚氏は自社開発チャットアプリの初回リリースに間に合わなかった機能の開発をそのまま続ける。

2018年9月

9月半ばにはuser-serviceの実装がおわる。がつなぎこみやら他の作業で時間がとられる。GCE Ingress Controllerの小回りが効かないのでNginx Ingress Controllerにする。次は手数料率の関係で乗り換えることになった決済代行サービスとのつなぎこみとその管理にpayment-serviceをつくることにする。

2018年10月

payment-serviceをリリースする。決済代行会社独特のサーバとのつなぎこみに、前職で経験があるとはいえ手間取る。またユーザーリストの可視化に簡単な社内向けのVue(Nuxt.js)アプリをつくることにする。

2018年11月

社内向けのNuxt.js Appをリリースする。ユーザー対応の一部自動化の強化にむけて、外部APIとの接続部分の追加実装にはいる。同僚氏がシュッとつくった簡単なNode.jsアプリケーションがGAE上でうごいていたが、障害対策・フロントエンドとの責務をわけるためにも、設計だけじゃなく言語もGoでやり直す決定をして実装をすすめる。

2018年12月(予定)

外部APIとやりとりする兼botサーバがGolangで書き直してデプロイされる。急にユーザーからの相談がスパイクしても安定して稼働できるようになるはず。

リリースの速度について、多い日は1日3回くらいやっている。これはイメージサイズの小ささやk8sのリリースの簡単さによって実現されている。マイクロサービスで責務が分割されているのもこれに拍車をかける。各マイクロサービス間の接続はgRPCでやる。k8s上に展開したDeploymentが管理するPodと、そこへのアクセスを提供するServiceを1つのnamespaceにデプロイして、他サービスからはk8sクラスタ内でDNS解決させて運用している。今はあまりアクセスも多くない関係上なんとかなっているが、今後普通に大きくなっていくと、ロードバランスをちゃんとするとかダウンタイムをなくすとかの普通の運用を普通にがんばる必要がある。今現在のダサい運用のひとつ。

ということで

もっと詳しく気になるひとは全員このURLをおす → https://goo.gl/forms/CbGUU1rRhMSXDfMH3