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

あさ寝坊 @知床 Asanebou @Shiretoko のレビュー

２月のことになりますが、北海道に行った時にお世話になった「あさ寝坊」という宿に行った時のレビューを嫁が書いていたので、Gengoを使って翻訳してみました。
残念ながら、投稿済みのレビューを編集するには色々とステップが必要ということで、ちょっと面倒なので、ここに貼付けてるだけです。

2020年にオリンピックがあったり、日本を観光大国にしようという国の取り組みをちらほらニュースで聞いたりするので、こういった日本語で閉じてしまっている情報がもうちょっと気軽に広まっていくといいんじゃないかな〜と。

original (Japanese)
http://www.tripadvisor.jp/ShowUserReviews-g1114386-d1145454-r197967690-Asanebou-Teshikaga_cho_Kawakami_gun_Hokkaido.html

The inn holds very fun memories from when I was single, and we stayed there as a family with our 4-year-old and 1-year-old children.
The price of the food was very cheap considering the portion and taste, and in a way unbalanced, and my husband who loves food was very satisfied!
Before leaving, they granted our audacious request to play in the snow, even though we didn't have any snow gear, and we parents played with sleds too for the first time in decades! The children were really laughing and it was a very fun time.
Their 6th grade daughter played with us, and when we were going home, I was able to feel the growth in our 4 year-old daughter who held herself from crying when saying goodbye.

母の日

２週間前になりますが、母の日の手紙を子供に準備させたのですが、文字を書けるようになったことに感動したのでここに記録。"いつもありがとう" の部分は母の日らしさを演出するためにこっちから書くように指示してしまったけど、好きに書かせれば良かったな〜とちょっと反省 w

ちなみに英訳(by Gengo) するとこんな感じになるそうで。こういうとっかかりから英語学習を始めのもありか？

You know, you know what, this is a flower. So please take good care of it. Thank you always

カーネーションは猫に荒らされ、すぐにダメになってしまった。

RDBMSとMongoDB

丁度、MongoDBのことが社内で色々と話題になっている時に、タイムリーにこの記事がでてきて、自分的に凄くささったのでメモ。
Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

データベース設計ができない/できなかった/する時間が取れない、といった人たちや、Shardingのためのロジックを書くのがめんどくさい、といった人たちを中心に好まれるデータベースです。Facebookでも、子会社の中にMongoDBを使っているところがあります。
　MongoDBを使うか、RDBMSを使うかという議論は、よく「先に楽をして後で苦労するか、先に苦労して後で楽をするか」という表現にたとえられます。「技術的負債」を語る上で良いモデルケースと言えるでしょう。
　稼働までなら、MongoDBの方が、正規化が必須なRDBMSより楽です。その一方で、設計を放棄したツケは、後々になってデータ整合性問題、(重複値の多発による)データ量増加、それによるコスト増といった様々な負債となって現れます。裏の実装はMyISAMと大して変わらないので、データ量がメモリに乗らないくらいの規模になってくると、InnoDBよりも急激なペースで参照・更新性能とも悪化します。典型的な「技術的負債」のパターンと言えるのではないでしょうか。

英訳 (by Gengo)

The debate about whether to use MongoDB or RDBMS is often described as being analogous to the expression, “To play now and work later, or work now and play later”. I believe that the situation we find here is a suitable model for talking about “technical debt”.
If we were only to consider the matter up to the point of operation, then MongoDB is the easier option because it does not require normalization like RDBMS does. On the other hand, the cost of abandoning design will surface later on in the form of various burdens such as the problem of data consistency, and (due to the frequent occurrence of duplicates) rises in data quantity and cost. The underlying implementation is not much different from MyISAM, so if data cannot fit into memory, both the referencing and updating performances will decline at a pace more rapid than InnoDB. It can be said that this is a classic pattern of “technical debt”.

MongoDBの売りとして、"スキーマレス"によるイニシャルコストの低さという所がフォーカスされているようですが、一方でNoSQL系の誕生の背景としては、Webシステムの拡大に伴う、ストレージの"スケールアウト"の必要性という所があったはずで、自分は後者の印象のほうが強かったので、ユースケースが真逆でチグハグだな〜と感じました。

• スキーマレス
  • テーブル定義しなくてもデータを格納できる。
    • サービスをさくっと始める所にフォーカス
• スケールアウト
  • スケーラビリティを維持するためACIDからBASEへ (下に参考スライド有り)
    • サービスがでっかくなった時に必要な概念
    • 一貫性を犠牲にしてもスケーラビリティを手に入れたい時

しかも、スケールアウトという、後で楽するための所に強いプロダクトなのに、スキーマレスの設計によるツケで、後で苦労するプロダクトとされているのも聞いてて残念な感じ。

ただ、一方で、例えば、世界的に使われててボクも大好きなfoursquareはMongoDBを使っていたり、アメーバもMongoの採用事例で色々とスライドを見かけるので、MongoDBがフィットするユースケース/使い方というのも確実に存在していて、そういうユースケースがもうちょっと抽象度を挙げてキャッチーな言葉でまとめられるようになると、違う見え方がするのかな〜と思ったり。
Mongo on Hadoop | Foursquare Engineering Blog
AmebaのMongoDB活用事例

あと、これは自分で色々想像してて気になった所で、スキーマレスでさくっと始められるというのは長所として挙げられますが、運用して2,3年経った時にどんな感じになってるのかな〜？と。スキーマ定義のドキュメントが無いとかはまあよくある話だと思いますが、RDBMSであれば、DDL引っ張ってくれば、最低限の情報とその定義に基づくレコードが格納されているという状態は保証されますが、スキーマレスだと、DDL無いし、Modelクラスがコードに定義されていたとしても、そのModelクラス自体が変遷したりしているわけで、運用の仕方によっては、むかーしの予期しないレコードでバグが出るとか、migrationが超大変とかありそうだな〜と勝手に想像しました。この辺は使ってる人に、どうやってるのか話を聞いてみたい。

ACID, BASE, CAP定理に関しては、この資料が凄くまとまってて勉強になりました。

NoSQLに関するまとめ from Gosuke Miyashita

これ絡みで最近読んだ本

データベースの限界性能を引き出す技術　?NoSQLに飛びつく前に知っておきたい原理と最新テクニック

Software Design (ソフトウェア デザイン) 2014年 03月号 [雑誌]