KubeCon + CloudNativeCon China 2018 参加報告 2019/1/16 山田直行 「Kubernetes on Supporting 1 Million Bike-Taxi Drivers in Indonesia」の解説

Kubecon + CloudNativeCon China 2018で特に印象に残ったセッションの中から、イン ドネシアのGo-jekという企業の事例を紹介します。 せっかく中国での開催ということで、中国企業の事例も聴講したのですが、 ・参考にできないくらい規模がでかい。その点Go-jekは規模的に身近に感じた ・中国企業は中国語によるセッションになり、同時通訳経由では理解が辛かった ・中国はWeChatPay・Alipayを中心としたキャッシュレス社会が実現しようとしている。イ ンドネシアはGo-jekという配車アプリがキャッシュレス化を主導しているという意味で面 白い事例だと思ったため 概要

Go-jekとは バイクの配車アプリ。 人を乗せて目的地へ運ぶだけでなく、荷物の運搬やフードデリバリーなども頼める。生 活に関する総合サービス企業へと成長中。 Go-jekは2010年創業で、GoogleやTencentも出資しているユニコーン企業。 インドネシアだけでなく、タイ、ベトナム、シンガポールにも進出している。

Go-jekの発展

(旧)Go-jekのシステムアーキテクチャ ・サービスがKafkaのトピックを生成し、ワーカーがそれを処理してDBに入れる、その セットが数多くある　

Infrastructure as Codeの挑戦 ・Terraform ・Chef ・Ansible その間、管理するVMは2015年に3つだったものが、2018年には10000以上に

Project X 2016年末に始まった、’’scheduler agnostic”(Kubernetesなどのオーケストレーションツー ルに依存しない、という意味と思われる)なデプロイツー ルを開発するGo-jekの社内プロジェクト インフラの移行を順々に行っていくためにこういったツー ルを必要としていた。

WebUIを通して人が設定すると、汎用のマニフェストが生成されて、それがKubernetes 対応のマニフェストと、Nomadのマニフェストが生成される仕組み https://www.nomadproject.io/ Hashicorp製のコンテナデプロイツール

発生した技術的課題 1. 複数のスケジューラにうまく対応する抽象化が難しい 2. 1の結果として、KubernetesおよびNomadの更新に追従していくのが困難 3. プロダクト側のエンジニアにとってブラックボックスになり、何か問題が起きたときに プロダクト側のエンジニアだけで解決が困難

発生したその他の課題 1. Kubernetesへの移行にあたっては、1つのチームが集権的に主導することは悪くな い。だがそれによって知識はサイロ化してしまう 2. 少人数のチームで少しずつ始めるのではなく、組織全体で一斉に移行を始めてし まった。それによって問題が起きたときに一度に対処できなくなってしまった

人はなぜ落ちる？ なぜなら、這い上がることを学ぶためだ (by バットマン・ビギンズ )

プラットフォーム選定にあたって ● AWS+kops ● GCP+GKE ● DataCenter+KVM+libvirt+Kubeadm チームによって異なったインフラプラットフォー ムを用いている HELMを使っているチームもあるし、ProjectX でマニフェスト作ってデプロイしているチームも ある

Project Xの改善 Kubernetesに特化 より良い抽象化を設計 同時に1つの小さいチームで取り組む

Project XはGo-jekの国際展開にも活用された Go-Viet(ベトナムでの展開)のインフラ構築を4日で実現 リピータブル・イミュータブルなコンテナの特性によって異なる国でもMVP(Most Viable Product)を展開していくことができた ビジネスの成長に伴うインフラのスケーリングが容易にできた トラフィックが急増したときも、新しいVMをつくるよりはるかに早く新しいコンテナを作るこ とができ、MTTR(mean time to recovery)が短縮された VM時代と比べてCPU/Memoryなどのリソース効率の良さ、容易で堅牢な冗長化、コス ト効率の良さ、が実現された

Whiterabbit namespaceによるシャーディングを可能にする Custom Resource データサイエンティストチームがABテストをする際 などに活用 （自作？ OSSにはなっていなさそう）

Barito Log https://github.com/baritolog ログの設定を集約・管理するツー ル Go-jekによるOSS Stackdriver Loggingのようなログ 管理・監査・フィルタ・検索などを自 作したイメージ https://blog.gojekengineering.com/how-we-built-barito-to-enhance-logging-19f80b89496f

No content

https://github.com/BaritoLog/wiki

Cloud Nativeに関する社内勉強会の実施 これを聞いて驚いたのが社内勉強会が 土曜日実施なんだなということ...（土曜に 普通に働いている）

今後の展望 ● Minio(object storage for cloud) https://github.com/minio/ ● stolon(PostgreSQLのHA構 成)https://github.com/sorintlab/s tolon/ ● Ceph(分散ストレージプラット フォーム) https://github.com/ceph/ceph これらの組み合わせ 特定のクラウド・プラットフォームに依存していない分、 DBもマネージドサービスを使わずクラウドネイティブな手 法でやろうとしている。インドネシアでオンプレミス中心にやっているのは AWS/GCPのリージョンがないからとい うのも影響してそう

Q：VMからKubernetesへの移行を進めるうえで、VMのサービスとKubernetesのサービ スが相互に通信したいケースで、ネットワークのアクセス管理の課題が生じると思うがど う対処しているか？ A： ベトナムのケースではAWSのCNI Plugin（おそらくこ れ?https://github.com/aws/amazon-vpc-cni-k8s）を利用している。 ルートテーブルの設定数の制限？など制約があり、今後課題が顕在化してくるので対処 しないといけないと思っている 質疑応答

参考URL セッションURL(プレゼン資料のPDFリンクもあります) https://kccncchina2018english.sched.com/event/FuJX/kubernetes-on-supporting-1 -million-bike-taxi-drivers-in-indonesia-giri-kuncoro-iqbal-farabi-go-jek YouTube https://www.youtube.com/watch?v=7mIM-6gQ3fo Go-jek https://www.go-jek.com/ Go-jek Engineering https://www.gojek.io/blog/