Principles Of Microservices by Sam Newman を１年前に見たかった。

会社でshareされて流れてきた動画。かなり勉強になると同時に、耳の痛い所が色々とあったw。１年前に見たかったな〜としみじみと思った。ただ、後悔していても始まらないので、とりあえず、忘れないように内容のメモ。

Principles Of Microservices by Sam Newman

() 内は自分での補足や感想。

• Microservicesの定義 -> Autonomous services that work together. 一緒に動く自立したサービスの集まり。

なぜprincipleの話をするかというと、Microservicesをやるにあたっては多くの選択/決定をしなければならないので、軸となるルールを持っておくことが大事だから。herokuのthe twelve factors的な感じ。
(これは本当そうだよな〜と。とりあえず、Microservicesだ〜と色々と分けて作ることは出来るけど、変な分け方をした所はボディブローのように苦しくなってくるし、かといって、作る前から完全に見通すのはとても難しいので、ルールに沿ってるかをチェックすることで、大きな設計ミスが防げるのはとてもいいと思うし、そこからはみ出るにしてもしっかりとした理由づけができそう。また、そういう軸があることで、設計に関する議論も、抽象的なものから、もう一歩踏み込んだ所で議論しやすいように思う。)

以下、Microservicesの原則。

• Modelled Around Business Domain
  • Domain Driven Design is a good place to start
  • (エリック・エヴァンスの本を読み直した方が良さそう。)
• Culture or Automation
  • Infrastructure Automation, Automated Testing, Continuous Delivery
  • 初期コストはかかるが、最初の仕組みが整えば、加速的にサービスを増やすことが可能になる。
• Hide implementation details
  • Hide your database. 例えば、複数のアプリケーションを同じテーブルにアクセスさせると、カラムの変更が複数アプリケーションにまたがってしまうのでNG。代わりに１つのアプリケーションにだけサクセスさせ、他のアプリケーションからはAPIでデータを取得できるように。
  • 隠してる情報/フィールドをexposeするのは簡単だが、その逆は大変なので、最初はできるだけ隠す。
• Decenterize All The Things
  • self-service. 中央集権でなく、各チームで判断を下す。
  • Gilt ♥ Open Source / Making Architecture Work in Microservice Organizations
  • とりまとめ役になるMessaging middleware はsimpleに。
• Deploy Independently
  • Most important!!!! あなたのシステムがこれができている状態なら、結構、いい感じだよ。
  • そして、これが守られていないなら、新しいサービスを足す前に、その状況を直す必要がある。 (耳がとても痛い。。)
  • 複雑性を避けるため、大体の人がone hostにmultiple application ではなく、one host, one applicationに帰結していく。 ただ、one host, one applicationは効率的なリソースの使い方とはいえないので、one host, multiple applicationを容易にする点が、dockerが人気を集めている一つの要因。
  • consumer driven contract. consumerからのserviceの使い方を両者間の契約とみなし、service側の変更では、その契約に違反していない事をルールづける。
  • https://github.com/realestate-com-au/pactcom
  • (consumer driveの話はこの記事に詳しく書いてて分かりやすかった。 サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ )
  • (後でユニークIDは導入コスト高いみたいな話があったけど、これもかなり導入コスト高そうだなと思った。)
  • consumerをservice側の変更と同時にデプロイすることを強要することはNG。service側は破壊的な変更はせずに新しいAPI end-pointを用意し、consumerのupgradeを待って、古いエンドポイントを削除。 ただし、bug fixとかのservice側のメンテナンスはちょっと大変。
  • ( publicなAPIはどうすんだろう？と思ったけど、この記事で出てきたAPIs are foreverという言葉を思い出した。 10 Lessons from 10 Years of Amazon Web Services - All Things Distributed )
• Consumer First
  • swagger
  • 人間にも優しくね。 HumaneRegistry
• Isolate Failure
  • much easier to make less resilient, more machines, more network boundaries which can timeout. microservicesにすると、システムが堅牢になると思いがちだが、むしろ脆くなりやすい。マシンは増えるし、ネットワーク越しのやり取りも増えるから。
  • あるモノリシックな１つの巨大システムを12個に分割したけど、そのどれか１つでも止まると、全部が上手く動かなくなるという分割をした会社があった。私なら、１個の巨大サービスに戻す事をオススメする！
  • ↑のことをdistributed single point of failure って名づけた人がいた。 (この言葉は言い得て妙で、気に入ってしまった。他人事ではないがw。)
  • strangler app (level 7の振り分けのproxy layer?) を入れるパターンはあるあるだけど、そこがSPOFになりがち。一個のapplicationがthread poolを食いつぶしてしまうことで、全部のシステムがアクセス不可能になってしまう。
  • まずは妥当なtimeoutを設定しよう。
  • thread poolをapplication単位で準備するとなお良し。一つのアプリケーションがハングしても、他のアプリケーションには問題なくアクセスできるように。bulk head pattern
  • circuit breakers。エラーが繰り返される場合、timeoutを待たせるのではなく、素早くerrorを返してしまう。それにより二次災害を防ぐ。databaseアクセスにも使える。
  • (この辺は見事に踏んでた所なので、凄く納得。microservicesにすることで、異常系のパターンは増えるし、こういった仕組みも含めてしっかりとテストしないといけないな〜と。)
• Higly Observable
  • log aggreation
  • passing through correlation ids. 処理が始まった所でユニークなIDを発行し、全てのサービスのログで記録する。逆引きして、サービス間の依存関係をvisualizeするというお洒落なことをやってる人もいた。
  • ただし、correlationが欲しくなった時にはこれを導入するコストも高いよ。デバッグが大変なくらいシステムが育ってるから必要になる訳で、ある意味必然。
  • GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system

今の会社でもmicroservicesな感じで、色々分けだしているけど、障害につながったポイントや、ここ上手くいってないな〜と感じるポイントが、見事に指摘されていて、結構感動してしまった。いやー、ほんとに１年前に見たかった。。

違うイベントのだけど、多分ほぼ一緒なスライド。

Principles of microservices velocity from Sam Newman

www.slideshare.net

この発表者の方は、自分もちょっと前に読んだこちらの本の作者で、勿論、本のほうもとてもいいんだけど、結構なボリュームで、現在地を見失いがちになってしまったので、先にこの動画を見て、全体を把握してからこの本に出会いたかったな〜と思った。とりあえず、microservices怖くない。(ちゃんとやれば。)

Building Microservices

マイクロサービスアーキテクチャ

第17回ハイテクハーフマラソン を走った

「村上さんのところ」を読んで以降、すっかりはまってしまい、村上春樹さんの本やエッセイで紹介されている本をちょいちょいと読んでいる。
「村上さんのところ コンプリート版」読了した - seikoudoku2000のブログ
その中でちょいちょい出てくるランニング話に影響されて、自分も１０月から走り出した。特にこの本の影響はでかし。

走ることについて語るときに僕の語ること (文春文庫)

元々、ちょっと走ってみたいな〜と思っていた所をぐぐぐいっと背中を押された感じ。健康のため、仕事に必要な体力のためもあるけど、村上春樹さんの見てる世界に近付いてみたいな〜という何とも言葉にしづらいモチベーションに火がついたような(笑)。
読み終わった次の週末に、家の近くのMIZUNOショップに入ってみたら、１番いいな〜と思ったやつの丁度良いサイズがちょっと安くなってて、「これは運命だ！」と思って衝動買いして、ランニングウェアはこれまた家の近くのバッタもん屋で揃えて、1周1kmのジョギングコースをぐるぐると走っている。ここまでの所、大体月に100kmくらい。

途中ケガしたりで走れない時期があったりもしたけど、何だかんだと走り方のコツも掴めてきて、距離/記録ともに成長を感じられるようになったので、次ステップとモチベーションの維持のために、もう２週間も前になるけれど、人生初のハーフマラソンを走った。
右も左も分からずに参加したけど、事前に送付されてくる案内がしっかりしていたこともあって、特に迷う事無くスタートできた。スタート前のトイレがめちゃめちゃ混んでて、男子の立ち小便コーナーですら並んでみたら２０分以上かかって、出発の30秒前にトイレが終わったり(スタート遅れた人もいっぱいいたと思う)でバタバタしたことだけが次回への反省点。
天気良くて走ってて凄い気持ちよかったし、無事に目標の２時間切りを果たせて良かった^^ 順位は男子3053人中1759位だったそうな。まだまだ先は長い。
次はフルマラソン挑戦するぞ！

「村上さんのところ コンプリート版」読了した

村上さんのところ　コンプリート版

購入したのが7/24で、ついさっき読み終わった！
期間中、ずっとこれだけ読んでたわけではないけど、１ヶ月と３週間くらいかかった。感慨深い。
コンパクト版が紙でも出てるけど、村上さんがどっかの回答(ブックマークし忘れたのでもはや探索不能w)の中で、今回はたくさんの"量"を積み重ねることに意味があると考えている、みたいなことを書いていて、それはホントにそうだな〜とコンプリート版を読み終えて感じている。（ただ、勿論、紙のほうは読んでないので、実はそっちでも似たような効能を得られるのかもしれないw）
過去に村上春樹さんの小説は何度かトライはしたものの、あまり好きになれなくて、ゆえに、どんな人かも全然知らなかったけど、この本や、並行して読んだ他のエッセイや小説を通して、ボクも無事に(?)村上主義者になれた気がする。

この本はトピックもランダムだし、量も凄いので、感想は書きづらいけど、ボクが一番良かったな〜と思うのは、全体を通じて物語の必要性が説かれていたり、本を読む事が絶対的に肯定されていて、自分の中の読書熱がぐぐっと高まったこと。年齢と共に保守的になってきたようで、あんまり新しい作家さんやジャンルには手を出さなくなりつつあったり、その前から翻訳モノって食わず嫌いしたりしていたけど、色々と読んでみようかなと思い始めた。

以下、回答の中で紹介されてた本のメモ。"The great Gatsby"と"心臓を貫かれて"は何回も言及されてたので、この辺からかな〜。でも、一番始めは"鉄道大バザール"と決めているw。

「でもさ、あの長い旅行から帰ってきたら、留守中に女房が浮気しているのが分かってね、それで離婚したんだ。参ったよ。」とポールがこのあいだ打ち明けてくれました。

鉄道大バザール 上 (講談社文芸文庫)

鉄道大バザール 下 (講談社文芸文庫)

The Great Gatsby (English Edition)

グレート・ギャツビー (村上春樹翻訳ライブラリー)

心臓を貫かれて〈上〉 (文春文庫)

極北

The Goldfinch

すべての美しい馬 (ハヤカワepi文庫)

第三帝国の興亡〈1〉アドルフ・ヒトラーの台頭

ロング・グッドバイ (ハヤカワ・ミステリ文庫 チ 1-11)

ダーク・スター・サファリ ―― カイロからケープタウンへ、アフリカ縦断の旅 (series on the move)

はい、泳げません

三四郎

偉大なるデスリフ (村上春樹翻訳ライブラリー)

AWS Startup Tech 夏のLT大会で話した

こちらのイベントにお声掛けいただいて"Monitoring Gengo using Saas"というタイトルでLTをしてきた。eventdots.jp

モニタリングはボク自身、経験が浅く、探り探りやってるので、ちょっとでも他社の事例を聞けるきっかになればいいな〜と思ったのと、後、ここで出た話をベースにschooさんで授業が行われるかもという話があったので、モニタリングという分野は必須な割にニッチなポイントなのでそこそこ枠取れるかなと思ってチョイスしてみた。ちなみにschooさんでの授業自体は無事に開催が決まったとの発表あり！
スタートアップでのAWS(Amazon Web Services)活用事例 2015 高山 博史 先生 - 無料動画学習｜schoo（スクー）

私自身のLTはちょっとというか、大分ミスった気がするので次への反省。。言いたかったのは、devopsやらの概念の中でdevとopsの垣根をなくす事が大事！みたいなのがあったり、Continous Integrationという概念がかなり一般的になってきているから、それをモニタリングでもやっていこうぜみたいなことだったんだけど、前半で時間を使い過ぎてしまってグダグダに。。それでも、終了後に何人かの人に質問してもらえたので、そこは良かったのかなと。

Monitoring Gengo using Saas from Yosuke Tomita

www.slideshare.net

後はこちらで紹介されているように、ほぼ同性同名の方(ボクは点がないほう)と握手した。「じゃない方芸人」ならぬ「じゃないほうトミタヨウスケ」とならないよう、引き続き、頑張っていかないといけないな〜と決意を新たにしたwイベントとなりました。aws.typepad.com

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

Effective Monitoring and Alerting: For Web Operations

YAPC:Asia Tokyo 2015 に行った

早、二週間近く経ってしまったけど、YAPC:Asia Tokyo 2015の前夜祭と初日に参加した。初参加なのに最後ということと、ノベリティが充実していたので、記念になるかな〜と思って個人スポンサーなるもので申し込み。以下、感想など。

技術ブログを書くことについて語るときに僕の語ること

技術ブログを書くことについて語るときに僕の語ること - YAPC::Asia Tokyo 2015
YAPC::Asia 2015で技術ブログを書くことについて発表しました - ゆううきブログ
最初はどんなタイトルがブクマ稼ぎやすいかとか、週のいつ頃投稿すべきかみたいな話をネタを入れながら場を暖めて、段々と本格的なブログへの取り組み方や想いを語りつつ、締めとして、やっぱり読んでもらってフィードバックをもらったり、はてブによる承認欲求が満たされたりしないとモチベーション続かないから、最初に話したようなことが大事なんですよという、さすがに人気ブログを書いてる方だけあって、起承転結のある見事な組み立てのプレゼンだな〜と思いました。
ネタを寝かせてしっかり熟成させてから、時間をかけて書いている事がヒシヒシと伝わって、一朝一夕にできたブログではないんだな〜ということを改めて認識できた。最近読んでいる村上春樹さんの本の端々に出てくるポリシーとちょっと重なる所があったりするな〜と思ったり。

あと、個人的にはQiitaなどよりも、ブログのほうが「自分だけの場」みたいな感じがあるので好きですというようなことを言っていたのが、結構ささりました。何か若かりし頃の気持ちをちょっと思い出したというか (笑)。ということで、YAPCの感想をアップする前に２つほど書いてみた。このセッションと先に出てきた村上春樹さんの本の影響で、何かを書きたい熱が溜まったので、しばらくちょこちょこ更新したいな〜と。naoyaさんのこんなtweetも見つけたし。雇ってもらう時の切り札になることを期待しつつw

エンジニアは文章うまいほうがいい、文章うまいやつ雇えってDHHが言ってたよ、確か。

— Naoya Ito (@naoya_ito) 2015, 9月 1

Managing Containers at Scale with CoreOS and Kubernetes

Managing Containers at Scale with CoreOS and Kubernetes - YAPC::Asia Tokyo 2015
スライド: Managing Containers at Scale with CoreOS and Kubernetes
仕事でこれ系のものを使う可能性が濃厚なこともあり、技術的な部分では一番の本命のセッションでした。
使う可能性が濃厚みたいな感じながらも、あんまりキャッチアップできていない状態でしたが、ちらっとこれ系の話を見る度に混乱していた概念の説明(schedulerとかpodとか)がかなりキレイにまとめられていたし、デモも、○○しますってなった時に、ここどうなんのかな？と思った所をボクの心を読んだかのようにちゃんと表示してくれて、とても聞きやすくて、めっちゃ勉強になりました。
そして、質問もしてみた。53:10 辺りのnginxのconfigの更新に関して。こうやって動画で見直してみると、質問を言い直すってのは後から見る場合には大事なことなんだなと分かったし(もっとはっきりした声で質問しろという反省もありつつ、、)、答えの表現の仕方もとっても上手で、ほんと凄いな〜と。場慣れだけなのか、何か専門的なトレーニングもあるのかは分かりませんが、いつかこれ位のレベルのプレゼン/質疑応答ができるようになりたいな〜。
なお、質問の答えとしては、クラスタの外のフロントに置いたnginxのconfファイルの更新にはこういうツールがあるとのこと。

質問してみたら、これを紹介してくれた。frontに置いたnginxのconf fileの動的ファイルにはこれを使える。 #yapcasia #yapcasiaA / “kelseyhightower/confd · GitHub” http://t.co/4O8Law0UTY

— Yosuke Tomita (@seikoudoku2000) 2015, 8月 21

ユースケースとして、frontにnginx置いてproxyさせて、増減するバックエンドにつなぐみたいな構成は結構あるかな〜と思うんだけど、それをKubernetesだけで完結しなようになっているのは何か理由があるのかなという所まで聞けば良かったなと今になって思う。次に何かあったら聞いてみよう。

Conway's Law of Distributed Work

TBD - YAPC::Asia Tokyo 2015Conway's Law of Distributed Work - YAPC::Asia Tokyo 2015
通勤て子供と過ごす時間を減らしてまでするものではないよな〜という想いが日に日に強くなっていて、リモートワークというのはかなり気になる働き方なので、個人的な所で一番楽しみにしていたセッション。長い事リモートでやっている人なので、何かスペシャルな方法があったりするのかと思ったけど、組織を変化させることは大変、ツールにこだわる、それを使ってしっかりコミュニケーションするなどなど、やっぱり特効薬は無いよね〜という印象。一番印象的だった言葉は

Invite remote workers into hallway conversations

で、逆にここまでしないと上手くいかないんだなと。改めて、リモートワークしてない側にほうこそ、大きな意識付けや努力が必要だなと感じました。これに関連して、タイムゾーンが違う所で働くことに関してどう思うか？みたいな質問が出ていたけど、回答としては１人や少人数だけが違うタイムゾーンにいることはかなり難しいであろうということでした。"地獄のシリコンバレー"のくだりで、シリコンバレーの会社に在籍してそのハイレベルな報酬をもらいつつ、日本でリモートワークすることが最強の勝ち組だみたいな説を目にして、確かに！と思ったけど、その道のりは簡単ではなさそうですw。
リモートワークについてはとても興味があるので、このセッションや↓辺りを聞き直し/読み直して、しっかり考えたいな〜と改めて思いました。rebuild.fm

イベント全体

ただ規模がでかいだけのイベントじゃなくて、積み上げてきたものがあっての今回なんだな一というのが、色んな所から感じられる、とっても素敵なイベントでした。定番の人がいて、これまで積み上げてきたものをベースに若干内輪ネタ感がありつつも、しっかり外に開いてて、新しいモノを取り入れながら進化してきたみたいな。何となくボクが大好きなアメトーークの雰囲気を思い出したw。今回で終了ということで、一見さんで終わってしまうのが残念ですが、最後に来れて良かった。
写真はノベリティでもらったタンブラー。ボクの物になるつもりで持って返って来たけれど、ビールが美味しく飲めるので、家庭内で早い者勝ちになっている好評な一品。主催者の皆様、ありがとうございました&おつかれさまでした！

disrupting japanのepisode 21

rebuildfmから始まった、まさかのpodcastブームの再来で、最近、色々とpodcastを聞いている。その中の一つが最近教えてもらったdisrupting japanで、特にこのエピソードが面白かったというか、なるほどな〜ととても腑に落ちてささった。www.disruptingjapan.com

ざっくり内容をまとめると、日本でなかなかスタートアップが出てこなかったのも、最近になって出始めているのも、文化的なものは関係なく、単にリスクと報酬のバランス(-> Game Theory)が変わってきつつあるため。大企業での終身雇用が崩壊し、リスクが高まりリターンが減る一方で、スタートアップ周りではエコシステムが整ってきたことでリスクが減り、成功した際のリターンでも報われる環境が整ってきた。それによって、そっちに流れがきている。という感じ。

So many things that are labeled as “cultural differences” have much simpler explanations. There are perfectly rational (and even mathematical) reasons why we have not seen a lot of entrepreneurship in Japan over the last 50 years, why we are starting to see a lot more of if now, and why we are likely to see an explosion of Japanese startups in the coming decade.

Since starting a company has become less risky and more rewarding, we should not be surprised that more Japanese are making the perfectly rational choice to start a company today. So-called culture really has nothing to do with it.

起業したり、スタートアップで働くことに合理性 (rational and even mathematical reasons) が増しつつあるというのが、ありそうでなかった説明で、個人的にとてもしっくりきた。スタートアップがイケてるとか、リスクをとって挑戦してるみたいな雰囲気の記事をちょいちょい見るものの、何となくしっくりきていなかった。そこを、そっちのほうが合理的になりつつあるからという視点で考えられると今の流れが腹落ちする気がする。

一方で、忘れてはならないのはこういうエコシステムを日本に持ち込んでくれた先人(?というほど昔の人ではないけど)達の存在なのかなと。ボク自身は伊藤穣一さんや孫泰蔵の話を聞いて感動して、少しでもそっち側に近付きたいと思って自分のキャリアを考えるようになって今に至って居る。
2011-05-30 - seikoudoku2000のブログ
デブサミ2013に行った その１ #devsumi - seikoudoku2000のブログ
当時、話を聞いていた当時のことを思い出すと、ほんと環境はかなり変わったな〜と思うし、その陰には何も無い所から色々と持ち込んでくれた人達の色んな努力があったんじゃないかなと。インターネット起こりたての頃にバリバリ働いていた人たちをちょいちょい羨ましく思う事があって、自分もそういう時代に巡り会いたかったな〜と勝手に僻んだりしていたけどw、色んな選択肢をとることのハードルが下がってきていて、実は今のこの時代もとても恵まれているんじゃないかなと改めて思えたり。そして、逆にそういものが整っていない時代にリスクをとって挑戦していた人たちは、ほんとある意味クレイジーな人たちだったんだろうな〜と思えたり。

という感じで、自分の中の視野がぐっと広がった感じのする、ナイスなエピソードでした。

そして、このpodcastの最後はこんな言葉で締めくくられている。少子化とか何だかんだで、日本の先行きを不安視する声が大きくて、自分もついついそういうのを気にしてしまいますが、最近、家買っちゃったし、日本で頑張ってやっていきたいと思っているので、こういう見方してもらえると嬉しいし、元気が出る。頑張ろう。

Now I have no doubt that in 30 years, Japan will be a global engine, perhaps the global engine of startup innovation. Now I realize how absurd this claim sounds today. It sounds every bit as absurd as someone in 1870 saying that Japan would someday be a great industrial and military power. It sounds every bit as absurd as someone in 1950 saying Japan would rise to be great economic power. At yet, in both those cases, Japan defied the odds and not only managed to defy expert opinion and not merely catch up with the west, but Japan grew to become a global powerhouse. And we’re about to see the same thing happen with startup innovation in Japan.

PostgreSQLのFATAL: terminating connection due to conflict with recovery

PostgreSQLを運用していると時々見る FATAL: terminating connection due to conflict with recovery というエラー、問題になるたびに調べては見るんだけど、中々すっきりとした答えを見付けられないまま、日々が過ぎていたけれど、昨年のre:InventでのAmazon RDS for PostgreSQL Deep Diveの発表の中にめっちゃいい説明があった。iframe埋め込みでの途中から再生のやり方が分からなかったので動画へのリンクのみ。
AWS re:Invent 2014 | (SDD409) Amazon RDS for PostgreSQL Deep Dive

• vacuum_defer_cleanup_age
• max_standby_streaming_delay
• hot_standby_feedback

要件に合わせて、この３種類のパラメータをトレードオフを考えつつ、調整すべしとのこと。詳細は貼付けた動画+公式ドキュメントへ。

Amazon RDS for PostgreSQL Deep Diveというタイトルになってはいますが、ここで紹介した部分だけでなく、PostgreSQL内部の挙動に関してちょいちょいと説明があり勉強になったので、RDSユーザに限らず、自分たちで運用している人も時間が許す時に挑戦してみるといいと思えるおすすめなセッション動画でした。

もうちょっと説明足したの書きました
seikoudoku2000.hatenablog.com