読者です 読者をやめる 読者になる 読者になる

台風の中GitHub Japanを雑に訪問してきました

GItHub Office

元同僚のP氏が現在GitHub Japan社にいるのですが、よくSwarmでチェックインしているのを見てSwarmヤクザを自認する自分としては、これは一度チェックインせねば気が済まないということで訪問してきました。

エントランス

f:id:a-yamada:20160920181329j:plain:w350 f:id:a-yamada:20160920181733j:plain:w350

ちなみにGitHub Japan社は芝大門にあるビルのワンフロアにあります。

オフィス雑感

数席の執務スペース、MTGルーム、和室、ラウンジスペースで構成されてるシンプルなオフィス。訪問当時はP氏ともう1名だけしかいらっしゃらず、基本的にはリモートワークが多いようです(まあ台風やったし)。

f:id:a-yamada:20160920181949j:plain:w350 f:id:a-yamada:20160920181857j:plain:w350

フロアの中央にはオレンジのコンテナっぽい箱があり、Octcatが見下ろしています。実は中身は畳が敷かれた和室になってます。堀があるので脚を下ろせるタイプですね。

f:id:a-yamada:20160920183649j:plain:w350 f:id:a-yamada:20160920183635j:plain:w350

和室は事実上P氏の占有スペースになっている模様。さすがと言わざるをえない。こういう和室スペースいいですね。

f:id:a-yamada:20160920183444j:plain:w400

ラウンジスペースにはポスターが。これはGitHub Shopにも売ってるやつですね。

宝の山

f:id:a-yamada:20160920182543j:plain:w400

GitHubのステッカーが雑にダンボール箱に入れられていたので、雑に十数枚頂いてきました。あとはOctocatフィギュアと、今はもう売ってないTシャツもらいました。

静かなオフィス

たまに他のスタートオフィスのオフィスとか行ったことあるんですが、集中できる空間を用意できているところが多いのと、とにかく仕事する上において意味の無いものが置かないというのがちゃんと設計されているとこが多い気がします。リモートが確立していれば今回のGitHub Japan社のようなシンプルなスペースで十分なわけですよね。

静かで集中できるスペースを作るという目的で動くというより、本質的に必要なものを突き詰めれば自然とそうなるのが理想といったとこでしょうか。

(参考)弊社

それに比べて弊社といえば、もちろん規模がでかいというのもあるんですがエンジニアやクリエイターがほとんどのフロアにもかかわらず、無駄なものが多いのです。社内キャンペーンのポスターをベタベタ貼ったり(貼りっぱなしで放置される)、Slackにあげれば済む共有資料をやたら紙で配ったり。紙を配らせないために以下のような策を講じたこともw

blog.stormcat.io

最近の極めつけはこちらでしょうか。

f:id:a-yamada:20160921083347j:plain:w400

こんな大量の紙誰が使うねん(そこ通れねーし)

Go1.7系でVisual Studio Code(vscode-go)の補完がぶっ壊れる件の修正方法

Go vscode

ちょっとの間Kotlinを書いていたら、その間にGo1.7.1まで行ってて昨日重い腰を上げてアップデートしました。それは良いとして、当方GolangVisual Studio Codeで書いているんですが、アップデートの弊害かコード補完が効かなくなりました。

github.com

問題が起きたのは本体というよりvscode-goプラグインですね。

実際に以下のissueにもあがってます。

github.com

この画像のように、オートコンプリートの候補PANICとしか出ないようになりますw

f:id:a-yamada:20160921095457p:plain

もしかしたらハマる人もいるかもしれないので雑に回避方法を共有しときましょう。

回避方法

以下の手順で回避できます。gocodeをアップデートし、gocode closeするだけ。

$ go get -u github.com/nsf/gocode
$ gocode close 

自分の場合、結構古いgocodeがローカルに存在していたのでトラブったみたいです。

gRPCとgrpc-gatewayでWebオペレーションの形を再考してみた

先月、GoogleがgRPCのバージョン1.0を発表しました。

osdn.jp

gRPCとはGoogleが公開しているHTTP2ベースのRPCフレームワークで、Protocol Buffersでサービスインタフェースやリクエストやレスポンスのデータ構造を定義します。特定の言語に依存しないメリットがあり、かつ型の恩恵も受けることができます。Protocol BuffersのIDLでデータ構造やインタフェースを定義すると、C++/C#/Java/Go/Ruby/Python/Objective-Cといった言語のクライアントプログラムを自動生成できるため、生産性でも強みが有ります。

最近ではMicroservices構成におけるサービス間通信によく利用されたり、iOSAndroidといったモバイルアプリケーションからも利用されつつありますね。FRESH! by AbemaTV でもバックエンドのサービス間通信で一部gRPCを利用しています。

www.grpc.io

変わりつつあるWebオペレーション

Webオペレーションの形は変わりつつあると感じています。ちょっと前ならシェルスクリプトで様々な運用スクリプトを書いたり、シェルがしんどいケースではPythonRubyを利用したり、AWSGCPにもCLIツールがあるのでそれをスクリプトからキックしたりといった運用が多かったと思われます。

ただ、この流れですがGoが台頭し始めてから変わってきたのではないでしょうか。Goは型があって静的言語ではありますが非常に手軽にCLIツールを書けますし、ビルドしてできたバイナリを配置すれば実行できて、かつクロスコンパイルできるのでポータビリティにも長けています。運用系のツールを書くのに今一番適した言語じゃないかと感じてます。

今のプロジェクトでもかなり時期の段階(1年半くらい前)でgRPCを検証していて採用するつもりだったんですけど、某JavaのプロダクトにバンドルされてるJarの内部にあるProtocol Buffersの別バージョンと衝突して問題が起きたりして、安定稼働には少しリスクがあったので見送ってました。最近の新しめなMicroservicesから投入し始めた感じで、本番運用も始めています。

実際に利用してみて生産性・安定性でも大きな手応えを感じていたのもあり、gRPCって実はWebオペレーションの領域にも向いてるんではないか?という仮説が浮かび上がった次第でありまして、今回のエントリとなります(前置きが長くなってしまった)。

grpc-gateway

実際にWebオペレーションの分野にgRPCを持ち込むとなると、一つ課題がありました。何かというと、grpcはProtocol Buffersを喋るため、HTTP経由でやりとりが可能とはいえ人間が解釈できるようなレスポンスを得ることはできません。運用系のツールや様々なミドルウェアが存在してますが、今となってはRESTfulなインタフェースを備えていないものの方が少ないでしょう。

その課題を解決するのがgrpc-gatewayです。

github.com

一言で言うと、grpc-gatewayはバックエンドにあるgRPC serviceに対してのReverse Proxyであり、クライアントに対してRESTfulなインタフェースを提供するものです。Protocol BuffersをJSONに翻訳する役割だと思ってもらえればいいですね。これによって、gRPCなエンドポイントとRESTfulなエンドポイントの両方を提供するものが作れます。

grpcでWebオペレーションの仕組みを再考した

gRPCとgrpc-gatewayベースでWebオペレーションの仕組みを再考し直しました。構成図は以下の通り。

f:id:a-yamada:20160920154311p:plain

Ops Service

運用系の処理をOps ServiceというMicroservicesが担当し、gRPC/RESTfulなインタフェースを提供。grpc-service側にはAuthの仕組みを配置することでオペレーションに対して適切な権限制御を行います。

FRESH!ではAWSをメインに利用しているので、基本的にはOps Serviceからはaws-sdk-go を使ったクラウドの制御を行うことが主目的です。

Hubot

Hubotを使ったChatOpsを行ってるので、HubotからはRESTfulにOps Serviceへの指示を行えるようにしています。

Ops Scheduler

Hubotでスケジューリングするっていう手もありますが、スケジューリングしたい運用系ジョブをOps Schedulerで行っています。これはGoで書かれたDaemonプログラムですが、Goにはcronのライブラリもあるのでcronチックなスケジューリングが簡単に記述できます。Ops SchedulerからはgRPCでOps Serviceへリクエストします。

EC2のAutoScaling Groupにスケジューリングでの縮退っていう機能がありますが、この機能では少し我々が必要なオペレーションを満たせなかったので、このスケジューラーを書くことで少し高度な縮退スケジューリングを実現しています。

Other Service

これはまだ何も作ってないですが、その他のMicroservicesからOps Serviceを利用したいケースもそのうち出てくるでしょう。そうなった場合にOps ServiceをgRPCでリクエストできるように作ります。もちろん、言語はなんだっていい。

まとめ

オペレーションもプログラマブルに、かつ型の恩恵を受けたかったり、CIを使って継続的に品質を担保したいという欲求があるならば、gRPCを使ったWebオペレーションはすごい良いと考えてます。今後も色々と知見を共有できるといいですね(^ω^)。