SRE チームの @yuya-takeyama です。
先日 Google 東京オフィスで行われた Kubernetes Meetup Tokyo #14 というイベントにおいて、発表の機会をいただきました。発表動画の撮影・配信も行われるホスピタリティの厚さにも驚きましたが、参加人数が多いこともあって様々なフィードバックをいただき、大変楽しませてもらいました。
この記事では当日に質問されたことなど、スライドに書かれていない点について補足していきたいと思います。
Amazon EKS (Elastic Kubernetes Service) は使わないのか
発表資料にある通り、現在は kube-aws を使用しており、これは CloudFormation 等を用いて Kubernetes クラスタを構築・アップデートを行うためのツールなので、現状は EKS は使っていません。
一番の理由はスタディサプリをデプロイしている Tokyo Region において EKS がまだ利用できないためです。グローバルに展開している (プロダクトとしての) Quipper も含めて足並みを揃えたいので、当面はそれを待っている状態です。あとは EKS でのコンテナの起動に Fargate が使えるようになってくると非常に魅力的なので、楽しみにしています。
また、kube-aws においても EKS の対応が進められているようなので、そちらもウォッチしています。
もっと長期的には GKE といった選択肢もあり得るかもしれませんが、まだまだ予定は未定です。
何故クラスタの複数世代を管理するのか
クラスタのアップグレードにおいて、クラスタを複数世代作れるようにして、出来上がったら徐々に入れ替えていく、という話を 34 ページ付近でしています。
複数世代を持つことなくエイヤ！でアップグレードするという方法ももちろん考えられますが、やはりそれでは何かあった時に怖いよね、ということで最悪ロールバックもできるようにしています。
何故 Ingress を使わないのか
まず Ingress を使わずにどうしているのかというと、29 ページ以降 で説明している service-router (ステージング環境においては branch-router) というコンポーネント (中身はただの Nginx) を type: LoadBalancer の Service を用いて ELB として Kubernetes クラスタの外に露出しています。
その ELB も Route53 の Private DNS を使って、Kubernetes 外の Reverse Proxy (これも中身はただの Nginx) から参照しているので、エンドユーザが直接アクセスするのはこの Reverse Proxy です。この Reverse Proxy は Kubernetes への移行を行う前からずっと使い続けるもので、mruby による不正アクセスの検知や oauth2_proxy によるアクセス制限など、既存の資産を使いつつ移行したい、というのが大きな理由であり、Ingress を積極的に避けているわけではありません。
終わりに
今回はたまたま私が発表することになりましたが、これらは CTO 始めとした SRE チームの全員を中心とし、チームの外の Developer からもフィードバックやディスカッションを通して協力してもい、Technical Advisor の @mumoshu さんにも日々助けてもらっています。つまりチームの成果です。
一歩一歩着実に進んで来れてはいますが、このプラットフォーム上でプロダクトが価値を出していくのはまだまだこれからなので、SRE チームもそのほかのチームも採用への応募をお待ちしています。
