Developers Summit 2019に参加した感想など
Developers Summit 2019(#devsumi)に参加してきました。会場は目黒のホテル雅叙園東京です。去年は仕事の都合上参加できなかったのですが、今年はなんとか両日とも午後を空けて参加してきました。
1日目 参加セッション
午後から参加しましたが、この日の目玉は何と言っても【14-G-1】のGCP特別セッションです。Googleの実際の開発手法やCI事情が聞けるなんてめったにないですから本当に楽しみにしていました。あと、なにげにこの日の最終セッションの技術書・ビジネス書大賞は世相を反映しているので毎年楽しみにしています。
Cloud Native時代における Docker / Kubernetes による開発
【14-A-4】 13:05～13:50 青山 真也[サイバーエージェント]
Kubernetes完全ガイドの著者によるセッションです。1/10にあったKubernetes Meetup Tokyo #15の発表も見ていたので、今回も楽しみにしていました。発表内容はタイトルどおりクラウドネイティブやKubernetesの解説だったのですが、その構成が素晴らしかったです。マイクロサービスとサービスメッシュから始めて徐々にブレークダウンしてKubernetesの話題にもっていき、最後にGitOpsで締める流れは非常に分かりやすかったです。もしクラウドネイティブやKubernetesにもやもやしている方はスライドを一読することをオススメします。ちなみにクラウドネイティブ関連ではJapan Container DaysやKubernetes Meetup Tokyo #15の参加レポートも書いているのでよろしければそちらもどうぞ。
いまなぜGoogle Cloud Platformを学ぶのか！？〜GCPを支えるGoogleテクノロジーと愛を語る〜
【14-G-1】 14:10～15:40 中井 悦司[グーグル・クラウド・ジャパン]、他
さて、本日一番楽しみにしていたGCP特別セッションです。さすがGoogleだけあってテーブルはコンセント付きで、Wi-Wiカードもあって、コーヒーとお菓子付きで、バレンタインデーだからかもしれませんがGCPを象ったチョコとクッキーも貰いました。至れり尽くせりですね。
本題のGoogleの開発環境に関するプレゼンですが、いろいろと予想外のこともあったので、手元のメモからなるべく詳細に書き起こしてみました。
- 共通ミドルウェアサービス
- 分散ファイルシステム、分散NoSQL、分散ロックマネージャ、分散XXX・・・
- 単一リポジトリによるソース管理
- Gitは使っていない
- １日あたり4万コミット、20億行のソースコード
- 全てのプロジェクトを一つのリポジトリに保存。プロジェクトごとにディレクトリに分けて管理
- 他のプロジェクトのコードも閲覧可能。任意のプロジェクトのコードをインポートリンク可能
- Pros
- プロジェクト間のソースコード共有の促進
- バージョン間の依存関係問題が起きにくい
- 大規模なリファクタリングが可能
- Cons
- 専用ツールの開発・メンテが大変
- ライブラリの依存関係の管理が大変
- ブランチを持たない開発ツリー
- ソースコードの修正は全てメインラインに反映
- リリースブランチのみ分ける（チェリーピックで必要な修正をメインラインから取り込む）
- 自動ビルドツールによるテスト駆動開発
- Blaze(Bazelに似たビルドツールで依存関係と自動テストのルールを指定
- コミット時の自動テストでは変更コードに依存する他の自動テストを全て実行
- １日あたり1万3千個のプロジェクトにおける、約80万回のビルド処理と1億5000万回のテストを実施
- 自動テストの工夫
- 定期的に発生するチェックポイントでテストを実施(重複テストを削減)
- リソース効率は良くなるがテスト結果が遅れるのでストレスになる
- 依存関係が遠いテストの実行頻度を落とす
- 定期的に発生するチェックポイントでテストを実施(重複テストを削減)
- ソースコードの更新プロセス
- リポジトリ全体を(仮想的に)ローカルにコピー
- ローカルで修正した内容をコードレビュー
- レビュー終了後にリポジトリにコミット
- レビュー前後に自動テストを実行
- コードレビューシステム
- CL[^1]ごとに変更部分をレビュー
- Critique(Gerrit[^2]に類似のレビューシステム)上で実施
- 軽量なレビュープロセス
- レビューアのアサイン後、小さなもので1時間、大きなもので5時間いないにコメントを受け取る
- 開発者は平均して週3時間のレビューを実施
- 99%のCLでレビューアは5人以下、75%のコミットでレビューアでは1人
- 90%のCLで変更されるファイルは10以下、35%のCLで変更されるファイルは1つ
- 一つのコミットの変更行の中央値は24行、10%のCLで1行のみ変更
- コードレビューの目的
- 他人が理解できるコードを書くこと
- これが絶対の基準。開発者の入れ替わりが早いのでこれが最重要。
- 理解できない場合は、「理解できない」と突き返せばよい
- 他人が理解できるコードを書くこと
個人的な感想としては単一リポジトリとブランチを持たない開発ツリーは結構衝撃でした。勇気をもってメインラインに突っ込む！は大胆だなぁと思いましたが、後続の話を聞いて納得しました。要はローカルの修正結果を自動テストしてレビューしてもらうシステムがありきなんですね。一般的にはレビューしてもらうにはブランチを切ってコードレビューシステムと連動している共有リポジトリにプッシュしますが、Googleはコードをリポジトリに突っ込むことなくローカルのコードをレビューしてもらえるシステムがあるので、常にレビュー済みのソースのみがメインラインに突っ込まれるようです。まぁ、それでもメインライン一本の運用はすごいと思いますが・・・
あと、コードレビューの目的もシンプルでイイねをしたくなりました。コードレビューの目的を他人が理解できるコードを書いているかのみにすれば、それを徹底すればバグは明白になるし、開発者の入れ替わりでも問題が起きにくくなるので非常に効率的だと感じました。コードレビューのチェックリストをたくさん覚えるよりもこっちのほうが効果がありそうです。
上記のプレゼンは下記の公開資料にもとづくそうなので、いつか読んでみたいと思います。
- Why Google Stores Billions of Lines of Code in a Single Repository
- Modern Code Review: A Case Study at Google
- Taming Google-Scale Continuous Testing
- Lessons from Building Static Analysis Tools at Google
セッションの二本目はパネルディスカッションで、Googleエンジニアの経歴紹介やGCPとの関わり等を聞けて非常に興味深かったです。気になった話題で言えば、Javaの"Write once, run anywhere"は嘘[^3]というパワーワードが出ました。なぜこの話題が出てきたかというとGCPがアプローチを変えてWrite once, run anywhereを達成したという矜持からだと思います。Googleのサービスは今や世界中で欠かせないインフラです。そしてGCPでコードを書けばGoogleのインフラに乗せて世界中に動くサービスを提供することができます。これは恐らくSunの達成したかった本質であり、GCPが誇っていい真実だと思います[^4]。
あと情報収集の仕方も話題になりました。Googleエンジニアでもブログ[^5]、SNS、RSS、SlideShar、Qiitaは一般的な情報源のようです。面白かったのはスマホのChromeでおすすめ記事の表示がトップ画面にでてきますが、これが意外と自分の興味にあった記事を勧めてくれるそうです。
[^1]: Change Listの略。一回のコミットに含まれる変更ファイル
[^2]: GerritはGoogleが開発したOSSのコードレビューシステム。GerritはCritiqueを元にOSS化されたものらしい。
[^3]: Javaでクロスプラットホーム開発したことあるエンジニアになら大抵知っていることですが、まともな製品を開発をする場合は大抵JVMの下側がWindowsなのかLinuxなのか、はたまたAndroidなのかは当然意識します。要はWrite once, run anywhereは言い過ぎってことです。特にインストーラ周りは壊滅的だし、UIは残念なことになります。というのも結局はJVMでは最大公約数的なアプローチしかできないから、それで事足りる分はいいのですが大抵はそれだけではうまくいかないからです。もちろんこれは当時のSun Microsystemsが掲げた理念に過ぎないのかもしれませんが、Java生誕から20年以上経った今でも達成されていないことを考えると完全に誇大広告だったということだと思います。
[^4]: GCPの場合スケールさせることができるのでWrite once, run everywhereの方が近いかもしれませんが、これもさすがに言い過ぎ感があるので忘れてください・・・
[^5]: 日本語ブログはありがたいのでブログ書いて！と訴えていました。このブログが届くとは思いませんが、まぁ書き続けたいと思います・・・
【祝】k8sデビュー！ エンタープライズ巨大アプリをマイクロサービス・コンテナ化。段階的移行(中)の全記録を追う。
【14-D-7】 16:20～17:05 石田 健亮[ドリーム・アーツ]
既存のJavaアプリをKubernetesを用いてマイクロサービス化する話でした。k8sを用いたモダナイズの事例としてとてもよい発表だったと思います。
- 旧環境
- Angular,Velocity,Struts,俺々PersistenceAPI,MySQL
- 新環境
- AKS, SpringBoot, kustomize, fluentd(サイドカーでログ収集、DaemonSetを使ってノード単位で立てる)
- 工夫した点
- マイクロサービスは重い(実測で4倍遅い)
- キャッシュを利用
- 非同期、並列にする
- マイクロサービスは重い(実測で4倍遅い)
- Netflix OSSをチェキラ
「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会
【14-A-8】 17:25～18:45
密かに楽しみにしていたセッションです。やっぱり本を読むのって時間がかかるのでなるべくハズレは引きたくないものです。かといって売れているから自分にあっているとも限らないので悩ましいところですが、ここでは著者または関係者が読みどころをプレゼンしてくれるので、非常に参考になります。今日行われたプレゼンも非常に熱がこもっていて、実際に自分が投票した2冊は絶対に買おうと思いました^6。
そして2019年の大賞はこの2冊に決定しました。おめでとうございます。
2日目 参加セッション
2日目も午後からの参加でしたが、雪が降っていたので積もらないことを祈るばかりでした。雅叙園前から駅に向かう坂は激坂なので・・・
機械学習システムのアーキテクチャ アラカルト ～ BrainPad における実例を交えて～
【15-C-3】 12:10～12:40 太田 満久[ブレインパッド]
データ活用を生業としている会社からの機械学習の適用事例をおよびパターンの紹介で非常に参考になりました。一番のポイントはデータ分析が必要とされる場面でも機械学習はオーバースペックのケースが多々あって、その場合は古典的な統計処理を利用しようという事と、機械学習を利用する場合でもなるべく既成のAPIを利用するようにして、独自訓練は避けようというものでした。やはり独自訓練は大量のデータが必要だしコストも高いので、実践では費用対効果を考えながら必要な精度を見極めて、最低限の作り込みにする必要があるみたいです。途中の独自vs既成で出てきた Cloud AutoMLは使ってみたいと思いました。
あとバッチ推論の方がオンライン推論よりも非機能要件がゆるくてデータサイエンティストが行うモデル設計の環境に近いというのもなるほどと思いました。推論はリアルタイムで行うものばかりだと思いこんでいましたが、要件さえあえばバッチ推論の方が問題は少なさそうです。
エンジニアの皆さんに贈る最速キャリア戦略
【15-B-4】 13:05～13:50 松本 勇気 [DMM.com]
CTO大変ッスね・・・という感想がまず一言。生き急ぎたい人向けのセッションでした。自分は途中で振り落とされましたが、正論は正論なので生まれ変わったら実践できる人になってみたいです・・・
- AWS・GCP実弾演習場はマジうらやましぃ
- 暇なら仕事量増やしてください・・・
- カッツモデル・・・ヒューマンスキル・・・ツライ
- 全部Hello Worldはつらいよね？ 取捨選択大事
- マネジメントはみんなが学ぶべき概念
- 正しい意見より、解決できる意見
- ITエンジニアとして学んだスキルは他の分野にも流用可能
- 人はオブジェクトでメッセージパッシングで動いていると捉える
- 自分を知ってもらう。自分の能力・目標について、周囲は思ったほど知らない
- ジョハリの窓
- 意思決定者が誰で、何で困っていて、何を目標として、何を考えているのか
- それを知って自分がそこにどう貢献するかを考える
- 意に沿わなくとも、組織の意思決定内容に貢献する
- 時間をすべて経験に変換する
- 意思決定されたことに反対するのに無駄な時間を使うな
- 文句があるなら意思決定に絡む努力をすること
- 「正しいことをしたければ、偉くなれ」を思い出した・・・
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -
【15-D-5】 14:10～14:55 幾田 雅仁 [gumi]
すごい軽妙なトークで引き込まれました。まさしくElixirはWeb開発のための言語だと思います。 今年もErlang & Elixir Festをやるそうなので、是非参加したいと思います[^7]。
- Pros(楽しさ)
- Elixir + Phoenix はWeb開発に割り切れば学習容易
- 適当に書いてもCPU(コア)を程よく使い切ってくれて、そこそこ速くて、安全
- GCでシステム全体が止まることはない(プロセス[^8]単位でメモリを持ち、GCする)
- Cons(辛さ)
- EVM[^9]は高機能だが、カッコいい機能は沼なので、Web開発時には無視すること
- モジュールは誤解されがち。関数単位で考えること
[^7]: 過去2回は両方参加しています。もともとElixirはRuby on Railsのコミッターが作った言語で文法もRubyに似ていることからRubyユーザが多い印象です。
[^8]: ここで言うプロセスはOSのプロセスではなく、Elixirのプロセスです。一般的にはアクターと呼ばれる非同期処理の単位です。
[^9]: EVM=Erlang VM。ElixirはErlang言語の仮想機械(VM)であるEVM上で動作します。Java言語のVMであるJVM上で動作するKotlinやScalaのようなものです。
サーバーレスで最高に楽しめるアプリ開発
【15-B-6】 15:15～16:00 江藤 武司[Riotz Works] スライド
リアルタイムの動画やフィードバックを始めて扱う場合でも24時間、3人で作れるよ、という感じのセッションです。楽しそうですね。肝はPWAとFirebaseとAWS(Lambda,DynamoDB)、SkyWayといったところでしょうか。サーバレスアーキテクチャなのでイベントドリブンでサービスをラムダで繋いでいく感じですが、そのことをピタゴラ装置と言っていたのが非常に面白かったです。あとDynamoDBでレコードの生成イベントやTTLイベントをトリガにする話も参考になりました。サーバレスは基本的にポーリングではなくイベントを如何に活用するかがキーポイントなんだなと改めて感じました。
ちなみにサーバレスなので費用は使った分しかかからないわけですが、このようなイベントでもワンコイン(500円)程度しかかからないそうです。
無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜
【15-B-7】 16:20～17:05 池山 邦彦[Datadog]
Datadogを使った監視のお話です。Datadogはデフォルトの監視設定が豊富に提供されているので基本的なOSやアプリの監視で困るようなことはなさそうです。あと長年弱点と言われてきた外形監視ももうすぐ使えるようになるそうなので非常に楽しみです。余談ですが、Datadogの社員は犬派よりも猫派が多いらしいです。このブログ名のとおり自分も猫派なので、親近感を覚えました(笑)。あと話題の 入門監視もやはりオススメらしいです。
- なぜ無意味なアラートが発生するのか
- 監視する必要のないものは監視しない
- 通知する必要のないものは通知しない
- モニタリングのポイント
- ワークメトリクス
- スループット, 成功, 失敗, パフォーマンス
- リソースメトリクス
- 使用率, 飽和度, 失敗, 可用性
- イベント
- 変更, アラートスケーリング
- APM
- ログ
- ワークメトリクス
- モニタリングの種類
- 閾値, 外れ値(Outlier), 異常値検知(Anomaly), 予測(forecast), ログ, APM, 複合条件
- もう少しで対応予定
- 外形監視
- サービスが本当にReadyなのか確認できる
- 外形監視
Webアプリのチューニングバトル「（社内）ISUCON」の魅力と楽しさ
【15-B-8】 17:25～18:25 櫛井 優介[LINE]/古川 陽介[リクルートテクノロジーズ]/南 直[Wantedly]
パフォーマンスチューニングバトルの ISUCONのお話です。名前だけは聞いたことあって最初は海外コンテストをリスペクトしてるのかなと思っていましたが、どうやら日本発祥のコンテストだったみたいで元々の意味は椅子(ISU)を投げるから取ったみたいです。ちなみに正式名称はIikanjini Speed Up Contestです。面白そうだったので過去問あさって見ようかなという気分にはなりました。優勝賞金100万円のISUCON9も開催が決まったようですが出場するかどうかは未定です・・・^10
場外バトル
場外でも熱いバトルと言うか、宗教戦争が繰り広げられていました。
現場からは以上です[^11]。
[^11]: 自分はEmacs派ですが、このブログはVS Codeで書いています・・・あと好きな言語はRubyとScalaです。ただ機械学習の関係でPythonを使う機会も増えてます・・・
まとめ
やはり参加して良かったです。特にGoogleの開発環境なんて今まで聞いたことがなかったので非常に面白かったです。また、このブログでは全然書ききれていませんが現場の空気感とかセッションの盛り上がりとか実際に参加してみないと分からないことだらけなので、もし機会があれば来年も参加したいと思います。
本記事はデブサミに参加したくても諸般の事情で参加できなかった人や、興味があるけどいろいろと悩んでいる人のためになるべく面白さが伝わるように心がけて書きました。その結果長文になってしまいましたが、本ブログを読んでデブサミに興味を持っていただけば幸いです。
ちなみにデブサミ関連の資料は以下のリンクにまとまっていますのでご参考まで^12。
