Media Do Tech Do Blog

株式会社メディアドゥのエンジニアによるブログです。

GopherCon 2019に行ってきました

f:id:kentfordev:20190904171849p:plain

GopherCon 2019 会場入口*1

こんにちは。シニアエンジニアの濱口です。 以前に下記の記事で掲載したGopherCon 2019への参加しましたので、イベントの様子や体験をレポートします。

techdo.mediado.jp

プラン

会場はアメリカ カリフォルニア州 サンディエゴの、マリオット マーキスというホテルです。

イベントの日程は 7月24日から27日までの4日間のため、23日に出国し、28日に帰国しました。イベント本番は25日から27日まで3日間ですが、今回は24日のプレカンファンレンスにも参加をしました。

  • 24日: プレカンファレンス
  • 25日: セッション1日目 + ウェルカムパーティ
  • 26日: セッション2日目
  • 27日: コミュニティーデー

プレカンファレンスはイベント本番とは別料金であり、内容は丸一日かけたワークショップなどです。今回メディアドゥから参加した私と武田は、Kubernetesのワークショップに参加しました (Go & Kubernetes sitting in a tree)。

コミュニティーデーは運営側によるセッションではなく、開発者同士のふれあいやLT大会など、インタラクティブな1日です。今回はLT大会を聴講しました。

渡航小話

渡航のルートは、成田空港 → ダラス空港 → サンディエゴ空港、のルートを選び、トランジットを挟む形としていました。当日は成田空港で1時間フライトが遅延しまして、ダラス空港への到着が遅れ、トランジットの飛行機を逃してしまいました!

武田が英語はネイティブレベルで話せますので、なんとか事情を説明して替えの席を獲得できましたが、行きについては到着後の予定に影響すると現地で困りますので、トランジットは挟まないほうが良いと思いました。

現地の様子

ホテル内はGopherくんだらけ!

会場周辺の設備には至るところにGopherくん含むイベント案内が貼り付けられていました!

f:id:kentfordev:20190904174058j:plain
メディアドゥ 武田と、GopherCon案内板

f:id:kentfordev:20190904183630j:plain
プロジェクタ投影でGopher君

ホテル周辺の環境

サンディエゴはカラッと晴れており日差しは強かったものの、湿度が低く過ごしやすい環境でした。ホテルは海辺にありますので、ロケーションも最高でした!

f:id:kentfordev:20190904190042j:plain
水が綺麗です

f:id:kentfordev:20190904190128j:plain
会場のホテル外観

カンファレンス会場

メイン会場は参加者を全員収容可能であり、それ以外にもセッション用の部屋が用意されていました。

f:id:kentfordev:20190904190820j:plain
メイン会場、オープニング直前

f:id:kentfordev:20190904190455j:plain
スポンサー企業一覧

スポンサー企業のスペースには、ゲーム機も設置されていました。いくつかのヒントから映画のタイトルを当てるもので、難なく正解できました。

f:id:kentfordev:20190904190944j:plain
キーボードが設置されたアーケードゲーム機

参加人数

Goユーザの拡大に伴い、順調に参加者も増加しているようです。

f:id:kentfordev:20190904214256j:plain
参加者は順調に増加傾向

ワークショップの内容

プレカンファレンスとセッションで受けた、技術的な話題についてレポートします。

プレカンファレンス - Kubernetes

Kubernetesと、Kubernetesを用いた開発・運用をサポートするためのツールに関するワークショップです。

ワークショップ用のGitリポジトリを各自で参考に、下記のような手順を踏みました。参考プログラムはGoで書かれています。Goがシングルバイナリにコンパイルされることで、コンテナによる運用との相性が良いことなども再確認しながら進めていくことができます。

  • 簡単なREST APIベースのアプリケーションが題材
  • モノリシック -> マイクロサービス へと徐々にプログラムを分解
  • やっていくと、自然とアプリケーション分割の技術が身につく

Kubernetesのコマンドであるkubectlを用いて進めていきますが、ワークショップではツールチェーンの紹介もあり、それぞれの強みや、用途を学ぶことができました。紹介されたツールの名前の羅列とはなりますが、下記が説明されていました。

Helm, kubectl, Forge, ksync, kubefwd, Okuteto, Telepresence, Draft, Garden, Jenkins X, Skaffold, Tilt, kubefwd, Squash, Stern

Kubernetesの使い方だけでなく、モノリシックからマイクロサービスへの分解方法にも触れた、非常に有意義なワークショップと言えます。私自身、Kubernetesはそれほど触ったことはなく、業務での利用もあまり視野に入れていませんでしたが、実際に触れて有効なツールがあることもよくわかりました。私が業務で携わっているシステムは、今まさにモノリシックからマイクロサービスへ分解していけるような施策を練っており、業務の面でも活用ができそうです。

なお、ワークショップの講師は上記のツールにも名前があがっている、Garden.ioのEllen Körbesさんと、Goで書かれたグラフデータベースであるDgraphのFrancesc Campoy Floresさんでした。

Francescさんにワークショップ後、下記の質問をしました。ワークショップ自体も有意義でしたが、質疑応答もそれに並んで有意義でした。

Francescさんへの質問 - マイクロサービスとKubernetesについて

Q : マイクロサービスを Kubernetes で運用するかは、いつ決める?

A : 最初からでも良い。 Kubernetes の導入は大げさと思うかもしれないけど、機能を絞っても使える。2つしかサービスがないマイクロサービスでも、それが4つ、5つと増えた場合も同じ方法でスケールできる。複雑ならKubernetes 一択でいい。でも、シンプルにできるならいっそサーバレスでも良いと思う。

Q : では、マイクロサービスにしよう!って決断は何をきっかけにするべき?

A : 2つ。リリース作業が不便になった時と、リソース使用量が過多になった時。不具合を早く修正したいが、他の開発と影響し調整が必要になり始めたら検討すべき。分け方は、Martin Fowler のブログ ”context boundary“ が参考になる。リソース使用量はスケールで問題になる。フロントだけスケールしたいのに、利用が少ない部分まで一緒にスケールしたら合計メモリ使用量が跳ね上がる等。最初からマイクロサービスにして成功することはほぼない。リリース後一定のタイミングでこういった問題が発生するため、その際に検討を始めるのが良い。

Kubernetesは使いこなせばかなり複雑なこともできますが、必要な機能だけを必要な際に使うだけでも良い、というアドバイスは非常に参考になりました。

ワークショップから得られたこと

私としては、下記の点が得られたことです。重ねてになりますが、業務での利用シーンも想定できるという点で、とてもためになったかと思います。

  • Kubernetes は身近に使える
  • とりあえず動かすくらいなら1日で使い始められる
  • そのまま使うとCLI操作が辛い所あるけど、ツールチェインが優秀
  • マイクロサービスに対する心理的ハードルが下がった

セッションの内容

私が今回のイベントで聴講したセッションは下記です。動画はGopherConの運営から全てYouTubeにアップロードされており、誰でも見ることができます。

1日目

  • On the Road to Go 2
  • How Uber "Go"es
  • Portable, Immediate Mode GUI Programs for Mobile and Desktop in 100% Go
  • Go, pls stop breaking my editor
  • Handling Go Errors
  • Go Module Proxy: Life of a Query
  • The Gopher’s Manual of Style

2日目

  • The Athens Project - A Proxy Server for Go Modules
  • Generics in Go
  • You Can’t Go Your Own Way: The Standardization of Go at GitHub
  • Small is Going Big: Go on Microcontrollers
  • Optimizing Go Code Without a Blindfold
  • Dynamically Instrumenting Go Programs
  • Tracking Inter-process Dependencies Using Static Analysis
  • What Got Us Here, Won’t Get Us There

上記の中からピックアップして、いくつかレポートします。

How Uber "Go"es

下記について話されたセッションです。

  • Uber によるマイクロサービスの開発に関するセッション
  • サービス毎にGitリポジトリ作っていたけど、全部まとめた話
  • モノレポ(一つのリポジトリで全てのコードを管理する)の導入へ
  • そのためにやったこと、工夫点など

私は実務でマイクロサービスに触れたことがありませんので、Webや勉強会、書籍で取り入れた情報から、サービス毎にリポジトリを作るものだと考えていました。そこでモノレポという話が出ましたので、とても響いたセッションです。

まず、複数リポジトリによる管理でどうしても払拭できなかった下記が、Uberでの課題だったようです。

  • 複数のサービスが参照するコア部分となるリポジトリの変更が大変
  • コアのコードの変更が入ると、それを利用している数百のリポジトリにプルリクエストを送ることになる
  • コーディングの作法などの文化が乖離
  • サービス全体の把握は不可能で、誰も手がつけられない状態になる

そこで、モノレポへの変更に踏み切ったとのことですが、対策なしにモノレポに移行してしまうと、それではコードの変更による影響範囲の見極めが難しくなるなど、さらなるデメリットも生まれてしまいます。モノレポへの移行に当たり、工夫したことは下記とのことです。

  • Clean Architectureの採用
  • Clean Architectureを強制させるための、DI や 周辺パッケージの自作
  • 該当のリポジトリ
  • これらのリポジトリを使うことでサービスの組み方をある程度定型化

その他にもビルドやデプロイの点で工夫をされているかとは思いますが、全体の把握と組織全体の文化の浸透に大きく力を発揮したのは上記の施策のようです。具体的には下記のような恩恵を得ることができます。

  • コアのコードの変更による、多数のリポジトリに対するプルリクエスト地獄がなくなる
  • git clone が一つで済む、リポジトリ管理は大幅にコスト削減できる
  • cloneすれば全てのソースコードを手元で見ることができ、隣のサービスのコードも見ることができるため、文化の共有が楽、一貫性が大事
  • コードの書き方から、サービスの作り方まで手元のソースを参考にすれば、同様に構築可能

このセッションにおいて、一貫性という言葉が多く出たことが印象に残っています。別のセッションでも一貫性は大事にされていましたし、Goコミュニティ全体がGoを書く上で、いろいろな方面での一貫性を大切にしていることがわかりました。組織の中ではチーム・メンバの間の一貫性、Go全体においては、構文や設計に関する一貫性ということだと思います。

このセッションを受けて、私が所属しているチームではモノレポに挑戦しています。CI/CDでコード変更箇所に合わせて必要な箇所だけをビルド・デプロイすることなどは細かい検討や設定が必要そうですが、規模の小さいうちはまとめて始めてみて、軌道に乗ってきたらモジュール別で処理するなど、工夫をしていきたいと考えています。

Generics in Go

GoogleのIan Lance Taylorさんによるセッションです。上述のUberによる組織・チームによる運用を中心に添えた話とは逆に、コンパイラのことにも触れた言語そのものに関する内容です。いよいよ、Go2にむけてジェネリクスの実装が具体的になってきました。

Go自身のコードにおいて、現状は下記のような課題があるようです。ジェネリクスの実装により解決へ向けていくようです。私自身がまだGoのジェネリクスについて深くは理解できておらず、すこし大味な表現になっており、すみません。詳細なことは、Ianさん本人による記事に書かれています。

  • 抽象的なプログラミングは、現状でもinterface {} を上手く使えばできなくもないけど、もっと便利にしたい
  • interface {} を乱用すると型アサーションの地獄にもなりがち
  • 処理内容は大差ないのに、データ型が違うだけで関数が別々のものが存在する
  • 標準のソート関係のコードは冗長なものになっている
  • メンテナンス性などが徐々に低下
  • ただ、実行速度、言語のシンプルさを保ったままにしたい

おおよそこのようなところだと思います。ジェネリクスはパフォーマンスとトレードオフになりがちというところで、Goの持つパフォーマンスの良さとの兼ね合い、言語構文が複雑になりがちというところで、Goのシンプルさ、というところで工夫をされているようです。

具体的な手法としては、型パラメータ型引数コントラクトを言語仕様に追加するとのことです。これらの構文はジェネリクスを導入しつつコンパイルの速度を落とさないための工夫となるようです。

Ianさんと、メディアドゥ武田

弊社の武田がGoへコントリビュートしたセッションを、日本のGo conference 2019 Springで話していましたが、その際のプルリクエストをマージされたのがIanさんです。海外のカンファレンスに来た!と実感できる瞬間ですね。

全体的な感想

Goを言語として流行らせるための施策として、カンファレンスを運営されているということを感じ取れました。

  • 技術的な使いやすさだけでは流行らない
  • コミュニティとの触れ合いの場がたくさん設けられている
  • ジェンダー、国籍に関わらずいろんな人がいた、老若男女

私自身海外カンファレンスへの参加は初めてですので、下記のような不安がありましたが、実際にはフレンドリーで参加していてとても楽しめるカンファレンスでした。

  • 自身の技術スキルからついていけないのでは・・・
  • 英語は聞き取れても喋りはダメだし、どうしよう・・・

また、現地にはTwitterで繋がっていた日本人の開発者の方もいらっしゃいました。国内に目を向けたとしても、参加の意義がある場だと感じます。日本人以外でも、日本のGo conferenceへ逆に来日されている方と偶然出会えたり、とにかくGoユーザとして楽しめる場であったことは間違いありません。

さいごに

メディアドゥでは社員の海外カンファレンス参加を引き続き後押ししていきます。年末にはAWS re:Inventへ弊社の社員が参加を予定していますし、来年のGopherConも是非参加したいと考えています。

*1:The Go gopher was designed by Renée French and has a CC BY 3.0 license.