「GCPUG Tokyo December 2019」でお話させていただきました

昨日 12/18 に開催された「GCPUG Tokyo December 2019」で「ML アプリケーション短期開発 / Fast development for ML Web Service on GKE & GCP」と題してお話しさせていただきました。

内容は、つい先日の日曜日に小学生のお子さんを招いて「AI 入門」講座を開催したのですが、この日の体験学習のための開発した機械学習(ML)Web アプリケーションのご紹介です。
ML Web アプリケーションを短期間でどのように開発して、なぜ本番環境として GKE と GCP を選択したかお話しさせていただきました。

懇親会や Twitter などでいただいたご質問とコメントを元に本記事でいくつか補足を試みます。

「AI 入門」講座自体は今後のことは何も決まっていませんが、今回取材もしていただきましたので、もし次回が開催できた際にはぜひ多くのお子さんが参加していただけるとうれしいです。

DeNA、社員が小学生向け「未来のエンジニア」講座　:日本経済新聞

Why Kubernetes? Why not GAE or others?

「Google App Engine などの Web アプリケーション開発プラットフォームの方が簡単だったのではないか?」というご質問は何度かいただきましたし、私も今回のプロジェクトに関わってから何度か自問した問いでもあります。

これは大変興味深く私としても自分の日々の技術選定を含めて整理したいトピックです。
文書化を試みたら長くエモくなったので別の記事で書きます！

Other reactions

Frontend と BFF の接続について

質疑応答の中でp.17の構成図に関して「なぜ BFF はインターネットからアクセスできる必要があるのか?」とご質問いただき、回答させていただきました。
引用させていただいた Tweet はその質疑応答への reaction です。

時間オーバーしてしまい回答が言葉足らずになってしまったのでこの記事で再掲と補足します。
そもそも"BFF(Backends For Frontend)“という語が意味が広いと感じており、今回の BFF も「便宜上 BFF と呼んでいる Web API サーバーおよびサービス」です。

今回の構成では Tweet に書いてくださってる通り、Frontend では Next.js に隠蔽されたサーバーが立っています。
Next.js の機能で SSR もやってますが、今回のプロジェクトに関していえば SSR は特に必須ではなくメインは単に HTML, CSS, JavaScript の配信です。
この Frontend のサーバーは、強いて言えば「ちゃんと Not Found で 404 を返すために」立てています。

そのため BFF の接続元はあくまでブラウザの JavaScript になります。
したがって BFF へのインターネットからのアクセスは必要です。

参加されてる方々それぞれが思い浮かべる"Frontend"や"BFF"が指すものが異なっていた可能性があり、今回のご質問を受けてうまく説明できる言葉がないかなと思いました。

技術選定や導入について

新し目の技術を導入してることに関して懇親会含めて何名かの方から声をかけていただきました。

新しい技術であっても適していれば導入しやすい環境だと思います、おそらく。
慣れてしまったのですが、ロジカルではない理由で技術導入が進まないケースなどを見聞きすると恵まれていることを思い出します。

会社全体としてもロジカルかつ新しくても適した技術を導入しやすい傾向ですが、所属部署はその社内でも特に技術ドリブンで進めやすい環境だと感じます。
どこかで書いた気がするのですが部のトップ（つまり部長）まで、技術的な事柄を一切マスクや言い換えなしで相談できるのは大変ありがたいです。
議論も多くは Slack や時々メールや GitHub などで行われるのでエンジニアとしてはコンテキストスイッチがとても少ないです。

今回であれば Linux 開発機の導入を GitHub に貼ったベンチマークと必要費用だけで即決していただけました。
（ちなみに決議は Slack のプロジェクトの channel 上でした）

その分もちろん現場に責任があり、Linux 開発機を導入のためには Docker for Mac が確かに遅く、Linux 開発機でどのようなスペックであれば現実的なパフォーマンスとなるかは計測しますし、GraphQL 導入はプロジェクトの想定トラフィックが極めて少なく性能問題に直面しない確信があってこそです。

また本件に限らずハイスペックな Mac や Linux 開発機、CV 系の研究開発エンジニアの方が使ってる GPU ワークステーションなどは情シス部門の方の手厚いサポートあってこそで本当に日々感謝しています。
（今回も申請が受理される前に PC が準備されていました）

GitHub GraphQL Explorer

GraphQL、ブラウザだけあれば GitHub で気軽に試せるのでぜひ触ってみてください！
私たちも最初に試して「GraphQL ってこんな感じ」が共有できました。
そして次私がハマるまでに知見を世に溢れさせてほしいです！

Using the Explorer | GitHub Developer Guide

GPU 付き GCE インスタンスは急に落ちる

GCP では我々利用者が気付かないうちにメンテナンスが実行され、GCE インスタンスは通常であればライブマイグレーションつまり OS が起動したまま別のハードウェアに移動されます（すごい！）。
しかし GPU を繋いでいるとライブマイグレーションされずに強制終了されます。
ドキュメントに明記されてますしハードウェアを思い浮かべると「それはそうですよね」とは思いますが困ってます。

“GPU instances cannot live migrate and must terminate for host maintenance events.”

GPUs on Compute Engine  |  Compute Engine Documentation  |  Google Cloud

この記述、長らく日本語版ドキュメントには存在しなかったのですが今確認したら載ってました。
「毎月 1 回」なんてことはないです、2 日続けてインスタンス落とされた人知ってます。

さすが GCPUG、皆さんよくご存知ですね 😇
この話題で酒が飲めそうです 🍶

That’s it

資料作ってみたら案外 GCP の話題少なめで、GCP 関連のトピックを追加しようとしたら GCP 以外のトピックがさらに増えて「GCPUG なのに大丈夫かな?」と思ったのですが、さすが皆さん技術領域が広くご質問もいただけて嬉しかったです。
今回くらいの規模と複雑さで GCP 使うと Terraform でぽぽいと apply してインフラレイヤーは構築できてしまうので特筆できることが少ないのですよね（とても良いこと）。

当日はいつも知見 Tweet にお世話になってる@apstndbさんに初対面できて光栄でした。
あと kubectl のちゃんとした読み方教えていただきました！
cube control なんですね、なるほど。

ご参加いただいた皆さまありがとうございました！

About

Hidenori MATSUKI

🍣 🍶

another website: mazgi.com

TableOfContents

Categories

Tags

kubernetes docker docker-compose ml-engineering web-frontend