なぜそのプロジェクトでKubernetesが選択されたか

これは「GCPUG Tokyo December 2019」の記事から「Why Kubernetes? Why not GAE or others?」部分を切り出した記事です。
本記事のコンテキストとして、イベントでお話しさせていただいた資料「ML アプリケーション短期開発 / Fast development for ML Web Service on GKE & GCP」」を事前にご参照いただけると幸いです。

Why Kubernetes? Why not GAE or others?

なぜ今回のプロジェクトではより簡単そうに見える GAE やその他開発プラットフォームではなく k8s を提案したのか、私自身の技術選定基準やプロジェクトへの関わり方含めてこの機会に言語化を試みます。

まず、私自身は軽量に Web アプリケーションを開発することに強いモチベーションがあり、GAE はもちろん Firebase ファミリーや Cloud Functions, AWS Lambda は積極的に活用したいと考えています。
また所属している社内や部署内を見ても GAE とは限りませんが多様な Web アプリケーション開発プラットフォームの使用実績があります。
機械学習に絡んだところではServerless フレームワークを用いて短期間で Web アプリケーションを開発された実績もあります。

課題ドリブン、フルスタック AI 開発術 [MOBILITY:dev]

ではなぜ今回 Kubernetes(k8s) を提案したのか?
私自身としては次の 3 つの要因を元に「Docker Compose で開発して k8s に Deploy する」開発方針が適していると考え提案しました。

  • a. チームの現在のスキルセット
  • b. チームの Web サービス開発経験値とポテンシャル
  • c. 機械学習のシステム的な特性と制約

業務としてのプロジェクト完遂だけを考えるなら何を使っても同じように余裕はないながら間に合わせることはできたと思っています。
その上でどのような技術を選択したかによる差異は、k8s を含め汎用的で開発自由度に重きを置いた基盤を使えば世にある膨大な情報と選択肢から適した技術を調べ選ぶコストが発生し、GAE 等の適度に制約が加わったプラットフォームを選べば仕様が 2 転 3 転しより良いサービスを作ろうとする中で制約に気付き対処方法を考え乗り切るか諦めるか判断するコストが発生することだと考えています。

後者に関しては GAE であれば今回のサービスは完成したでしょうが、しかしチームメンバーがそれぞれ次に加わったプロジェクトでは適さない可能性もあります。
想定しやすい例としては以下です。

  • GPU 資源として Amazon EC2 P シリーズを使用しており Web アプリケーションだけ GAE を使うと運用コストと通信費が跳ね上がる
  • エッジデバイスや物理設備と接続する必要があり制約により通信経路が大きく制限される
  • Web サービスと同等のオフラインデモンストレーションが必要

かなりボカしていますがどれも私たちにとってはあり得るものです。
これらはいずれもある程度の Web サービス開発経験があれば適した技術を選択できるシチュエーションです。
そして適した技術を選択するために必要なのは Web サービス開発の基礎と経験だと考えています。

古いあるいはコンサバな考えと言われるかもしれませんが、私は 2019 年現在の Web アプリケーション開発の基礎は NGINX や Apache での HTML, CSS, JavaScript 配信や express().get() や http.ListenAndServe() や curl だと思っていますし、コンテナと聞くと Docker と合わせて LXC や chroot を連想します。
一方で GAE や FaaS は極めて高度な応用に見えます。（もちろんこれらはとても便利で良いものです）

基礎を知る機会がないまま「今回は GAE で」「次は XXX で」と異なる開発プラットフォームを使うことには、コンテキストスイッチによる負担が増し技術を深掘りする余裕がなくなると感じます。
実際、基礎を理解する間がないまま制約を回避するために毎回のように違う技術を使わざるを得ない状況は"振り回される"以外の何ものでもないでしょう。

私自身も経験がありますが「前回せっかく A を覚えたのに今回は A が全く役に立たないし新たに B を覚えないといけない」状況は無力感に苛まれあるいは強くフラストレーションを感じるのではないでしょうか。
「それも仕事のうち」と言い聞かせ納得することも時には必要ですが、努力は理不尽を飲み込み耐え続けるためではなく、時間効率を上げ精神負荷を下げ開発効率を上げるために行うべきでしょう。

せっかくなら「なるほど GAE は Docker とはまた違うコンテナなんだな、ということはランタイムはどうなっているんだろう？」「Lambda は結局 VM 上で実行されるのか、実行ごとにプロセスが起動されてるんだろうか? docker run とは違うのかな?」などなど、基礎の上に積み重ねて新たな応用技術を習得したいですし、その機会を提供したいと常に願っています。

基礎や原則を軸としディテールを関連付けていくことで理解が進み記憶に残りやすいことはよく知られていますし、多くの方が感覚的にも納得できるところだと思います。

このような考えのもと、汎用的で開発自由度に重きを置いた基盤としての k8s を提案しました。
一方で Docker Compose で開発し k8s に Deploy するとなると無数の Web アプリケーション開発技術を調べて選ぶコストが生じます。
このコストと負担は必要ではなく、少なければ少ないほど良いものです。
そのためコストと負担をごっそり削減することを狙ってサンプル(p.14)を作り叩き台としました。

「知の高速道路に乗る」という言葉がありますが、サンプルは知の高速道路に乗り、道路が左側通行なのか右側通行なのか、どの車線で時速何 km まで出していいのか教えてくれます。
サンプルを含めて導入できた技術はp.23以降の通りです。

ただ、今回のプロジェクトでは対面でディスカッションできる機会がとても少なかったのは事実で、例えば「Next.js or React or Material UI の境目がわかりづらい」などサンプルだけでは掴みづらい点が負担となってしまいました。
優秀なメンバーばかりだったおかげで本当にどうにか乗り切れましたが、どの技術を選択しても"ハマりどころ"みたいなものはあるのでどのようにその躓きを減らせるかは今後の個人的課題です。

That’s all

そんなわけで「短期間なのにしっかりした構成」と褒めていただけましたが、これはひとえに最高のメンバーが集まったことによります ❇️
「AI 入門」講座に参加してくださった小学生の皆さんもとても喜んでくださって我々も大きな達成感がありましたが、エンジニアリングとしてはより安定的に成果を出していきたいとも改めて感じた次第です。

あと Web アプリケーション開発に慣れてる方はお気付きの通り、これでも Redux や Job 管理は削ってますし、本番が 1 日限りかつ同時接続数極めて少ないということでパフォーマンスも運用監視も手付かずなので、Web サービスを作って運用するというのは本当に難しいですね。

極めて個人的な思い出ですが@onkさんの「Web アプリケーションは難しい」を今でもよく思い出します。
当時同僚としてこの話を生で聴けたのは僥倖でした。

良い機会をいただいたので言語化してみたのですが伝われば幸いです。

About

Hidenori MATSUKI

🍣 🍶

another website: mazgi.com

TableOfContents

Categories

Tags

kubernetes docker docker-compose ml-engineering web-frontend