勉強の為に引用しました。
https://www.infoq.com/jp/news/2015/09/microservices-with-go-kit
- 共有
- |
後で読
Golang UK Conferenceにおいて、Peter Bourgon氏がオープンソースのマイクロサービスツールキット「Go kit」を紹介した。これを使うことで、モダンな企業のアプリケーションスタックにおけるGoベースのサービス作成を簡単化、標準化することができる。
WeaveworksのエンジニアであるBourgon氏は、GoogleのGoは急速に「サーバの言語」になりつつあるが、モダンな企業ではまだクリティカルマスに達していない、という話でトークを始めた。この問題を解決しようと、Bourgon氏は「Go kit」を作った。これはマイクロサービスツールキットであり、大規模な技術組織におけるGoベースのマイクロサービス作成を簡単化（そして標準化）する仕組みを提供するものだ。
Go kitのトークでは、ツールキットのハイレベルな概要、その動機、利用シナリオが語られた。Bourgon氏はライブコーディングを散りばめながら、フレームワークでなされた重要なアーキテクチャ選択とそれを利用する意味について説明した。
トーク終了後、InfoQはBourgon氏と膝を交え、Go kit、マイクロサービス、企業におけるGoの利用について質問した。
InfoQ: 「Go kit」が何なのか、また、そのフレームワークを作る動機について説明してくれませんか？
Bourgon氏: 去年、私はSoundCloudのコアインフラストラクチャチームで働いていました。私たちはいわゆるマイクロサービスアーキテクチャのアーリーアダプタで、BazookaというHerokuライクな内部プラットフォームを構築して、サービスをコンテナ化して動かしていました。これらの多くはGoで書かれていました。Goはプロダクトチームにとってすばらしいものでした。すぐに学べて、メンテしやすく、リファクタリングも簡単です。運用にとってもすばらしいものでした。当時、Goのサービスは他の言語 (Ruby、Scala、Clojure、Node) と比べて、ビジネスオペレーションごとに使うリソースが1桁少なく済んだためです。ところが、年々、エンジアリング組織として複雑になってくると、チームは次々とScalaを選ぶようになりました。これは言語のせいではありません。というか、Scalaはひどいですからね。私はGoのファンなので、偏りがあることを認めますが、マイクロサービスにとって、特に大規模な組織にとって、間違いなくGoはパーフェクトな言語だと思っています。ですから、こうした突然の移行を目にするのは、残念でなりませんでした。なぜなのか、私は周りに尋ねました。それでわかったことは、ScalaというかJVMにはすぐれた「マイクロサービスの配管作業」のサポートがあるということでした。ここで言いたいのは、コネクションプール、安全性チェック、お行儀の良いエラー復帰、メトリクスとインスツルメントの管理、ログのルーティングといった作業はかなり退屈ですが、極めて重要なことだということです。SoundCloudはTwitterのFinagleスタックその他を使うことに決めました。どれもGoでもできることですが、Goでやるとかなり冗長になり、まだ安定したベストプラクティスもありませんでした。しばらくして、流れはJVMにありました。それで、私はそれについて何かしようと決めました。Go kitというのは、Goでマイクロサービスをやるためのスタンダード、ベストプラクティス、使えるコポーネントを提供しようとするものです。私たちはかなり独断的なコンポーネントを入れています。—サーキットブレーカー、レートリミッター、ロギングおよびインスツルメンテーションパッケージ、人気のあるサービスディスカバリプラットフォームに対するアダプタ — これらはばらばらでも、まとめてでも使えます。もしGo kitがうまくいけば、どんな規模のエンジニアリング組織も、自信を持って、ビジネスロジックにGoを選べるでしょう。
InfoQ: 単に標準のGoライブラリを使うのと比べて、Go kitはマイクロサービスを書くのをどう簡単にするのですか？
Bourgon氏: この質問には2つ回答したいと思います。第一に、Goの標準ライブラリは間違いなく、いろいろな意味でゴールドスタンダードです。Go kitはそれに取って代わるものではありません。むしろ、大規模なマイクロサービスに伴う課題に合わせて、標準ライブラリの周りに少し足場を組んでいるのです。たとえば、ユーザサービスを書いてHTTPで提供したければ、すべて素のnet/http.Serverでやれます。現在、GitHubはまさにそうしているプロジェクトでいっぱいです。おそらく、環境や要件などで、少し異なる想定があるのでしょう。これらのサービスもうまく、独立して動かせます。ところが、これらのサービスを、近くにいない開発者やチームが書いたものも含めて、たくさん組み合わせてシステムを作るとき、そこには必ず懸念が生じます。エラーの扱い方の違い、微妙に異なるログフォーマット、悪意のあるクライアントの扱いに関する哲学の違いなどです。ある規模を超えると、こうした違いは真の問題となります。あなたの構築した巨大で分離された分散システムが、今どんな状態にあるのか体系的に判断できること、それが本当に重要なことだとわかるでしょう。Go kitは、コンポーネント、共通の基盤、そうするのに必要なものを提供します。第二に、Go kitのコントリビュータは多様なバックグラウンドと組織からやってきており、マイクロサービスアーキテクチャ上、あるいはその内部にずっと取り組んできた人たちです。おかげでGo kitには、マイクロサービスの適切な動かし方について、実戦に耐えうる考え方とベストプラクティスが埋め込まれています。はじめたばかりの個人や小さなチーム、あるいは初めてマイクロサービスに移行する大きな組織の場合、長期にわたってマイクロサービスを大規模に運用することで得られる組織的知識を持ち合わせていないでしょう。Go kitはあなたにどうすれば良いのか指針を与えます。私はマイクロサービスでの間違いを目にするとともに、自分でも間違いをしてきましたが、Go kitのユーザが同じ間違いを繰り返さないよう、最善を尽くしています。
InfoQ: Go kitがターゲットとしているのは、どんな開発者/組織ですか？
Bourgon氏: Go kitの公式目標は、Goを「モダンな企業」におけるビジネスロジック・マイクロサービスの現実的な選択肢にすることです。「モダンな企業」というのは私の作った言葉ですが、SoundCloud、Spotify、Hailo、37Signals、Bit.ly、Imgur、Secretといった会社から、NetflixやTwitterといった本当に大きな組織までを含んでいます。これらは主として、コンシューマにフォーカスし、テクノロジドリブンで、成長にインセンティブを与えている会社です。彼らのインセンティブは技術的リスクを取ることを促します。そして、そうしたリスクが利益を生み出すことで、ソフトウェア業界の向かう方向が決まっていきます。今や私たちが当然だと思っている数々のアイデア — イミュータブルインフラストラクチャや、Dev/Ops、関数リアクティブプログラミングなど — はたいてい、こうしたモダンな企業における実験として始まったものです。私は同じようなサクセスストーリーの機会をGoに与えたいと思っています。ですから、Go kitはぴったり小さくなるよう作られています。もし自分でプロジェクトに取り組んでいるハッカーであれば、Go kitは自力でやるのにすばらしい体験を提供します。もしすでに出来上がったサービスを持っている小さなチームであれば、Go kitは大きな変更や中断なしに、同時に動かせます。
InfoQ: Docker、Kubernetes、インフラツールのHashiCorpスイートといったマイクロサービスを実現するテクノロジを書くのに、Goは人気のある言語になっています。このような領域でGo言語が選ばれているのは、なぜだと思いますか？
Bourgon氏: 実際、Goは急速にクラウドインフラの言語になりました。私はツールチェーンに大きく関係していると思います。単一のgoに、あらゆるモダンなプラットフォーム向けの小さくて、静的リンクされる、ネイティブコンパイルされた実行形式を生成できるコンパイラがあることがどれだけすばらしいか、いくら言っても言い過ぎではないでしょう。Goの単一であるという特性は、多くのインフラツールにとってGoを非常に魅力的なものにしています。その上、Goは事実上、実際にマルチスレッド（すなわち並列）ネットワークサーバを書くのが苦ではない、最初の言語だったと思います。私はC++からやってきた少数のひとりですが、まさにこれが理由でした。Goの並列に対するアプローチ — 言語に適切に組み込まれており、機能をクリーンに、言語の他の部分と直交するよう、かなり注意が払われていること — は、2009年において、また私の経験上、驚くべきことでした。そして、今日まで、それに匹敵するものはありません。
InfoQ: 関心のあるInfoQ読者がプロジェクトに参加したり貢献するのに、最適な方法は何ですか？
Bourgon氏: Go kitはまだ出来たばかりのプロジェクトで、やるべきことがたくさん残っていますし、興味深い成長の方向がいろいろあります。その将来は明るく、幅広く、コントリビュートに関心のある人ならだれでも、いわば最初から参加することができます。どうかgithub.com/go-kit/kitにあるGitHubリポジトリをチェックアウトしてプロジェクトの現状を把握し、Issueページから短期ロードマップを感じ取ってください。Google Groupsにメーリングリストがあって、さまざまな議論と設計アイデアを交わす良い場所になっています。また、gophers.slack.comにアクティブなコミュニティ、#go-kitチャンネルがあります。質問や提案があれば、ここが私や他のコントリビュータやユーザにコンタクトするのに最適でしょう。
InfoQ: 今日はどうもありがとうございます。他にInfoQの読者に伝えたいことはありますか？
Bourgon氏: この記事を読んで、自分の組織でこうしたプロジェクトを作ったことがあるという人は、アドバイスを共有したり、話を聞かせてください。私はみなさんの意見をぜひ聞きたいのです。どうかSlackチャンネルに来たり、メールしたり、Twitter @peterbourgonにコンタクトしてください。そして、— 特に — 自分の組織でGo kitを使うのに関心はあるけれども、特定の機能が必要だったり、うまく統合できるかわからないと思っている人は、ぜひコンタクトしてください。Goに強みを発揮させるチャンスを与えるため、みなさんと協力して必要なものを作るのを楽しみにしています。どうもありがとうございました。
Bourgon氏のGo kitに関するトークビデオは、Golang UK Conferenceのサイトで公開される予定だ。Go kitについて、詳しくはプロジェクトのサイトとGithubリポジトリを見てほしい。
0 コメント:
コメントを投稿