「サービスメッシュとは何か」について調べた
はじめに
最近、「サービスメッシュ」という語を見聞きする機会が増えた。
概念を正しく理解しておきたいと思って、このところ調べていたので、ここにまとめを記しておく。
サービスメッシュとは何か
TL;DR
Microservicesとして構成される分散システムにおいて、サービス間通信を担う専用のレイヤ。
サービスディスカバリ、負荷分散、トラフィック制御、通信のセキュア化などの機能を実現し、個々のサービスから利用可能にする。
代表的なプロダクトとして、 IstioやLinkerdが挙げられる。
出典
上のようにまとめるにあたって参照した記事、文書、書籍を紹介する。
若干、相互に食い違う内容があったので、適当に自分が穏当と思うように取捨選択した。
- What's a service mesh? And why do I need one? - blog.buoyant ... LinkerdやConduit*1の開発元であるBuoyant社CEOであるWilliam Morganの記事。Service Meshを語る上で紹介されることが多い(と思う)。
- Istio / What is Istio? - Istio Documentation
- ここではむしろ、サービスメッシュをMicroservicesに付随するネットワークや相互作用と見ている。
- Red Hat Developer | Introducing Istio Service Mesh for Microservices
私の解釈
もはや、当該レイヤで動作する(ソフトウェア)システムと定義してしまった方がしっくり来る。
なぜなら、上で述べたような機能を提供するもの(として認知されてきている)なので。
「service mesh」という語が登場するようになった当初は、単にMicroservices上のネットワークを指していたような表現が見られるが、いつの間にか「そのレイヤで動作するソフトウェア」という意味で述べられることが普通になってきたような気がする。
プロダクト
2018/8/11現在、自分が把握しているもの:
- Istio
- Envoy ... CNCF Incubation Project. Istio内ではプロキシ機能を担うコアコンポーネント
- Buoyant社製品(※OSS)
- Consul ... いつの間にか「distributed service mesh」となっている。また、Connectという新機能でsidecar proxyや通信の暗号化が実現される。
アーキテクチャー
サービスメッシュは上で述べたような概念のシステムなので、その実装は色々あり得るはずだが、IstioやLinkerdが事実上の標準実装となっているような向きがある。
正直、まだそんなに踏み込んで見てないのだけど、それらの構成要素は一致しており、よく似たアーキテクチャーとなっているようだ。
Istioのドキュメントから図を引用しておこう。
サービスメッシュ・システムの標準的な構成要素:
- Data Plane ... サービス間の通信レイヤ
- Sidecar Proxy ... 個々のサービス・プロセスとともに配置され、in/out双方向の通信を中継する。
- Control Plane ... クラスタ内に配置される独立したサービスで、様々な中央集権的機能を担う。例えば、プロキシの管理を含むData Planeの制御や、設定変更のためのAPIが挙げられる。
その他参考:
サービスメッシュが必要とされた背景
既に上に挙げたWilliam Morganの記事から、内容をかいつまんで訳す。
大規模なMicroservicesシステムはGoogleやNetflix, Twitterといった巨大企業で発展していった。
アプリケーションが多数のサービスに分割され、複雑化する内に、汎用的な通信レイヤが必要とされた。 しかし、それらは「重厚なクライアントライブラリ」の形を取った。
TwitterのFinagle, NetflixのHystrix, GoogleのStubbyが具体例だ。
それらこそが最初の「サービスメッシュ」だと言える。
この「重厚なクライアントライブラリ」の問題点は、以下だ。
- ライブラリによって、アプリケーションの開発言語やフレームワークが強制されてしまう
- 一方で、コンテナの普及により様々な言語で作られたサービスが動作することが普通になった
従って、「ライブラリ形のアプローチはもはや現実的ではない」と述べられている。
サービスメッシュが登場した歴史
LinkerdとEnvoyのどっちが先だったかわからないが、どっちかが最初だと思う。
2016年:
- 1/15 Linkerdの最初の開発版のリリース / https://github.com/linkerd/linkerd/releases/tag/release-0.0.7
- 2/18 Buoyant社のブログ中で「Service Mesh」という語について言及。 / Linkerd: Twitter-style Operability for Microservices - blog.buoyant
- 今のところ、自分が見つけた情報ではこれが一番古い。
- 9/13 EnvoyのOSSとしての最初のリリース / https://github.com/envoyproxy/envoy/releases/tag/v1.0.0
2017年:
- 1/23 LinkerdがCNCFの5番目のホストプロジェクトに。 / Linkerd Joins the Cloud Native Computing Foundation - blog.buoyant
- 1/31 Lyft社のMatt KleinがEnvoyによるService Meshについて発表。 / Lyft's Envoy: From Monolith to Service Mesh - Matt Klein | Microservices.com
- 4/25 Buoyant社 William MorganがService Meshについてブログ投稿 / What's a service mesh? And why do I need one? - blog.buoyant
他にもっとこんなのあったよ、という情報をお持ちの方がいたら、教えていただけたらここに追記するかもしれません。
終わりに
以下、雑感。
それなりの規模のMicroservicesを運用しているところだったら、なんらかの形でサービスメッシュ的なものを使っているのではないか。
一歩引いて、自分たちの環境におけるサービスメッシュに相当するものは何か、と考えると面白いかもしれない。
大規模で、コンテナを使ったサービスでMicroservices化された環境だったら、Istioなどの製品は相性が良さそう。
参考
*1:https://conduit.io/ Kubernetes向けの軽量Service Mesh
『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』を読んだ
ネットワーク系の知識を補強したくて、『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』という本のKindle版を買って読みました。
読了して、なかなか良い本だなと思ったので紹介しておきます。
特に、駆け出しのインフラエンジニアやネットワーク経験の浅いエンジニアにオススメです。
2013年の本ですが、ほとんどの内容は現在でも通用すると思います。
良かったところ
悪かった / イマイチかもしれないところ
- Kindle版が固定レイアウトのため、不便
- 1つひとつのトピックについてそんなに深くはない
過去に読んだネットワーク系の本について
今回以前にネットワーク系の本をちゃんと読んだのは、もう随分前だったように思います。
社会人になる前後ぐらいの時期に、『マスタリングTCP/IP』の入門編・応用編と『図解・標準最新ルーティング&スイッチング』という本を読んだことを覚えています。
当時とは変わってしまった常識もちらほらあるように思います。
まとめ
『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』という本を紹介しました。
インフラやネットワークに携わるエンジニアの方々の参考になれば幸いです。
インフラ専業でないエンジニアが、予備知識のために読む本としても良いように思います。
よろしければ、どうぞ。
おまけ:疑問に思ったこと
ほとんど余談ですが、この本の中では「サーバサイト」という言葉が注釈なく出てきます。
文脈からすると、「サーバ機器が設置される場所」という意味っぽい。
ネットワークの本に「サーバサイト」という謎用語が出て来たのだが。/ サーバサイトとは何か?サーバサイトとはなんですか? 調べても完璧にヒットするも... https://t.co/hyHgZjQvCW #知恵袋
— progrhyme (@progrhyme) 2018年7月6日
Healthtech Meetup #1 でLTしてきた
昨夜、縁あってこちらのイベントでLTをさせて頂きました。
今回は記念すべき第1回のイベントだったわけですが、私の属する会社含め、都内でヘルスケア関連の事業を営む複数のテック企業による合同イベントという形で開催されました。
そんなわけで、各々事業内容やサービスの内容を紹介しつつ、その裏側の技術要素に触れ、掘り下げていくという形の発表が多かったように思います。
私のLTについて
発表資料は下になります。
他はストレートなタイトルの発表が多かった中で、少し異色な題名だったかもしれません。
m3.comは医療従事者向けのサービスであって、一般の人がそのアーキテクチャー等を意識することはほぼないでしょうが、見えないところでこういうものが動いているのだという話もそれはそれで面白いかな(?)、と思いました。
スライドをよく見ると、私がこの資料で示されている2015年のリニューアルに全く関わってないことがわかると思います^^;
…なので、識者に話を聞いたり、社内資料を漁りながら発表の準備をすることで、私自身がm3.comのシステムを学ぶ良い機会になりました。
他の方々の発表について
各社特色がありつつも、技術的な理想と現実の折り合いを上手くつけているな、と感じました。
どなたかの発表で「ロックインされたくないけど、なるべくマネージドサービスに寄せる」という話があって、頷けるものがありました。
発表ラインナップの中で唯一アカデミック色の強いものがあって、それはDeNA望月さんによる『AI x 創薬の最近の研究動向』という題のものでした。
AIとは、創薬とは何かに始まり、創薬における機械学習や深層学習の応用例などを紹介して頂きました。
ふだん参加するテックイベントでこういう話を聞くことは珍しく、とても興味深い内容でした。
これらの発表資料は、まだWebに上がっていないものもあるようです。
手元で雑なメモを取っていたものをGistに上げましたので、リンクを載せておきます。*1
もしご興味があれば、ご覧ください。
公開スライド
5/24 0:15時点で、Connpassにはまだ資料が上がっていないようです。
私が把握できているものを以下に載せておきます。
終わりに
今回は歓談の時間は少なめでしたが、近い業界の色々な話を聞けて良い刺激になりました!
第2回以降もぜひ参加したいと思いました。
ありがとうございました!
*1:自分の発表の前後の部分などはがっつり欠けていたりします。悪しからず。
Ruby Hack Challengeもくもく会 #5 に参加した
一昨日、Ruby Hack Challengeもくもく会に参加してきました。
初回のCookpad Ruby Hack Challengeは昨年の8月末でしたね。
当時から興味のあるイベントだったのですが、記憶によれば、予定が合わなかったり抽選で漏れたり諦めたりしたようです。
そんなわけで、初RHCでした。
事前準備
空手で行っても資料を元にもくもく作業はできそうでしたが、一応前日に少しだけ準備して臨みました。
GitHubに公開されているRHCの資料を読みながら、手順をなぞってRubyをMac上でビルドしたり、C言語の開発環境を整えたり、といった作業をしました。
当日の流れ
会場はCookpadさんの12Fオフィスでした。
キッチンのある広いフリースペース的な場所で、少し大きめの勉強会などでも使われていると思いますが、今回は人数が少なめだったこともあって、1つのテーブルを囲んでみんなでもくもく作業しました。
自分は開始時刻の18:30ごろに到着したのですが、既に@ko1さん含む4名前後の方がいらっしゃってました。
PCを取り出すと、もくもくとRHC資料の続きを読みながら、途中の演習問題を解いていきました。
発展演習問題などは一旦すっ飛ばしつつも、一応最後の 5_performance.md
まで読み切ったところで時間切れとなりました。
その間にばらばらと参加者が集まり、終了間際の21:00過ぎになってようやく全員で軽い自己紹介を行いました。
MacにおけるC言語の開発環境について
とても久しぶりにC言語のコードを書くことになったので、開発環境を整える必要がありました。
自分の短いRuby歴(2年弱)では、ずっとVimで開発していましたが、型のある言語だとIDEの支援を受けた方が効率が良いだろうと思っています。
そんなわけでIDEを検討したところ、まあMacだとXcodeがスタンダードなのかなと思いつつ、最近流行りのVS Codeを試したい気持ちになったので、今回はこちらを使ってみました。
私の観測範囲では、VS CodeはJavaScript界隈などで人気が高まっている気がしますが、Rubyもextensionがありますし、上手くすればなんでもVS Codeで書けるような気もします。
もくもく会までにバッチリ使い込むには至りませんですが、コードの読み書きでそれなりに支援を得られるぐらいにはなりました。
もう少しVS Codeを継続してみようかなと思っていますが、Mac上でのC言語開発について、良い情報をお持ちの方はお知らせ下さい。
gdbの代わりにlldbを使った
VS Code上でデバッグするまでは行かなかったのですが、rubyをビルドするためのmakeタスクで make gdb
や make lldb
が用意されています。
実行するとソースコードディレクトリに置いた test.rb
を、その場でビルドしたruby(miniruby)を使ってgdb or lldbで実行してくれます。
初め、Macでgdbを動かそうと少し試していたのですが、結局上手く行きませんでした。*1
lldbはLLVMのライブラリを利用したより高機能なデバッガで、どうもMacではこちらを使った方が筋が良さそうです。
今後について
@ko1さんによれば、6月もRHCのイベント(おそらくまたもくもく会でしょうか)が開催されるそうです。
今回、私は下準備的なことしかできなかったので、できればまずは何か1つコントリビュートしてみたいなと思っています。
というわけで、来月以降も機会が合えば是非参加したいと思っています。
終わりに
イベントの開催、ありがとうございました!
GitLab Meetup Tokyo #7 に行ってきた
4/10にこちらのイベントに行ってきました。
気づいたときには一般参加枠が埋まっていたので、ブログ枠で参加しました。
…ということもあって、こうして記事を書いております。
最近GitLabを使うことが多いのですが、今回はコアな方々の話を聞けたり、今まで知らなかった機能やGitLabの思想にも触れることができて有意義でした。
- はじめに
- 発表スライド
- 感想
- 終わりに
- 聴講メモ
はじめに
会場はサイボウズさんでした。
全体で90名ほどの参加予定でしたが、席はほぼ満席で、活気のある雰囲気でスタートしました。
始めに、GitLab Tokyo / GitLab JPの案内がありました。
- Slack: gitlab-jp.slack.com ... メンバー200名超。
- Facebookページ: https://www.facebook.com/gitlab.tokyo/
Slackはどうやって入るのだろうと思ったのですが、HerokuでSlackinが動いているようですね。 検索すると見つかると思います。
発表スライド
Connpassに上がっているものもありますが、捕捉したものはここにも上げておきます。
(※随時更新します。)
Keynote「GitLabによるComplete DevOps」@shkitayama
LT①「How does GitLab manage git repositories?」@sotayamashita
LT②「GitLabのイシュートラッカー活用術」@jumpyoshi
LT③「GitLab CI & Docker in Docker」@toricls
LT④「カップラボ」@t_nakayama0714
LT⑤「State of Community Contributions to GitLab & GitLab 11.0」@tnir
感想
詳細な聴講メモは記事末尾に載せておきますが、ここでは印象深かった点を中心に簡単に感想を述べます。
続きを読むHugoのイケてるドキュメンテーション用Theme "Learn"と"DocDock"
はじめに
3年前(後述)に探したときは良いものが見つけられなかったのですが、時代は進んで便利なThemeが登場しているようです。
ドキュメントをHugoで作ると、Markdownでソースを管理できるのが良いですね。
この記事では主に"Learn"と"DocDock"という2つのThemeを紹介します。
Learn
Learn Theme for Hugo :: Documentation for Hugo Learn Theme
上がデモサイトにもなっています。
簡単に特長を紹介しておきます:
他にもいくつか機能がありますので、上のサイトを確認ください。
DocDock
こちらは、Learnのフォークですが、作者はLearnにもコントリビュートしているようです。
LearnのREADMEにcreditが載せられています。
Learnと違って多言語対応はしていませんが、独自機能としてreveal.jsによるスライド生成機能があるようです。
Bootie Docsとの比較
私自身も、3年前にbootie-docsというドキュメンテーション用のThemeを作って、ほそぼそとメンテを続けています。
正直に言って、bootie-docsよりもLearnやDocDockの方が機能が豊富で良さそうです^^;
特に、ドキュメントが増えてくると、メニューを一階層しか持てないBootie Docsでは苦しくなってくるかもしれません。
その他のTheme
ドキュメンテーション用のThemeは下のページを見ると他にもあります。
https://themes.gohugo.io/tags/documentation
ざっと見たところ、APIドキュメントを書くときはDocuAPIもよさそうだなと思いました。
先に挙げた2つのThemeは一般的な用途で使いやすそうです。
結びに
次にソフトウェアドキュメントを書くときには、LearnかDocDockのいずれかを試してみたいと思います。
3年前について
- Markdown による中規模ドキュメンテーションシステムについて調べた。 - weblog of key_amb
- Hugo で "bootie-docs" というドキュメンテーション用のテーマを作った #Hugo - weblog of key_amb
参考
Tour of Scalaを一巡りした
Tour of Scalaとは?
Tour of Scalaは、Scala公式サイトで提供されているScala初学者向けのチュートリアル的教材コンテンツです。
Golangの「A Tour of Go」のようなものですね。
Motivation
これに取り組んだ大きな理由としては2つあります。
前者については、自分自身がScalaのコードを書く機会は今のところほぼないのですが、書けるようになれば話は変わってくるかもしれません。
後者については、意識して取り組んでいたのは、かつて大学の授業でSchemeを触っていた頃ぐらいでしょうか。
他にも、例えばRubyを書いていて知らず知らずの内に関数型プログラミング的なアプローチを取っていたことはあるかもしれませんが、どういうのがそれなのかと聞かれると明言しかねる状態です。
然るに、関数型プログラミングはやはり大きなパラダイムであるので、これを学んでおくことは今後も必ず役立つだろうと思いました。
どのように取り組んだか
Scala開発のための環境構築ログはこちら。
IntelliJ IDEAでワークシートを作り、コードを貼って動作確認することが多かったです。
3/21〜24の4日間でTourを一巡し終えました。
以下は初学者向けのお役立ち情報です:
- https://docs.scala-lang.org/cheatsheets/# ... 構文の確認に役立ちます。
- https://www.scala-lang.org/api/current/ ... 標準ライブラリの仕様や用例の確認に。
- ドワンゴのScala研修テキスト
- Scala入門時に役立つ情報まとめ - Qiita
所感
Scalaについて、まだ機能の全貌は掴めていませんが、implicit機構など想像以上にパワフルな言語であることはわかりました。
一方で、LL並に簡潔に書けるような省略記法やシンタックス・シュガーがあることもわかりました。
関数型プログラミングについても、主要な登場人物らしき方々(第一級オブジェクトとしての関数、高階関数、カリー化、…)は現れたので、さわりぐらいは掴めたのかなと思います。
ただ、Tourを一巡しただけでは、特に関数型プログラミングについては学び足りないと感じました。
今後
そこで、上にも挙げたドワンゴのScala研修テキストの中で紹介されていた『Scala関数型デザイン&プログラミング』を購入することにしました。
こちらは、Kindle版だと50% OFFで購入することができました。
『Scala スケーラブルプログラミング』(通称、「コップ本」)でないのはなぜかというと、どちらかといえば、Scalaよりも関数型プログラミングの方を学びたいからです。
関数型プログラミングを学ぶ上では他にも良書がありそうですが、ひとまずはScalaの学習も兼ねて、こちらの本で勉強を進めようと思います。