20170201

Feb 1, 2017  

gRPC を見てみる

サービス間を型ありで繋ぎたい。アーキテクチャーの参考にもなるかと、ドキュメントを流し読み。

gRPC は Google が開発しているRPC(リモートプロシージャコール)のライブラリとフレームワークで、通信層は HTTP/2 を介して行われます。 データ層については、固定されている訳ではなくあくまでデフォルトで Protocol Buffers が使われる様になっています。使用出来るプログラミング言語は現在、C++, Node.js, Python, Ruby, Objective-C, PHP, C# となっています。

http://mattn.kaoriya.net/software/lang/go/20150227144125.htm

型だけじゃなくて、インターフェース定義

gRPCを使うと、クライアントアプリケーションは直接、ローカルのオブジェクトのように、他のマシンのサーバーアプリケーションのメソッドを呼ぶことができ、 分散したアプリケーションやサービスを簡単に作ることができる。 多くのRPCシステムと同様に、gRPCはサービスを定義し、リモートから呼べるメソッドと、そのパラメーターおよび返り値の型を記述するようになっている。 サーバーサイドではインタフェースを実装し、クライアントからの呼び出しをハンドリングするgRPCサーバーを実行する。 クライアントサイドでは、サーバーと同じメソッドを提供するスタブを持っている。

http://sambaiz.net/article/12/

ほう。コネクションさえしてれば、クライアントのメソッドのように呼べる。 インターフェース定義を共有して、コネクションに対して、ローカルメソッドのように呼び出すことができる。

r, err := c.RetEcho(context.Background(), &pb.EchoRequest{Say: "hello"})

https://github.com/grpc/grpc

Gitlab melts down

GitLab.comがオペレーション中に謝って、DatabaseのDataを消してしまったらしい。各リカバリー策もうまく動かず。

https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/?mt=1485916372982

悲しすぎる。問題の発生とリカバリーの試みのログがみれる。 https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

時間がかかりすぎる処理、スパムによる高負荷、それによる、レプリケーションのラグの発生、遅い時間の作業、同僚のヘルプが休みで得られないタイミング。いろんなことが重なって、opsが少ないと起こりそうなことな気がした。

  • バックアップが動いているかのテスト
  • opsをひとりにしない
  • 作業を分割する
  • 夜にsudoは使わない