ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

はじめてのMongoDBを読んだ

はじめに

読んだ。

はじめてのMongoDB (I・O BOOKS)

はじめてのMongoDB (I・O BOOKS)

結構薄いんで先にばーっと読んだしまったあと、(MongoDB イン・アクションもこのあとばーって読んだ)検証環境でざーっと動かして2周した感じだ。

最初の一冊としてざっと全体感をつかむにはちょうどいい。ただどのみちがっつりやるならMongoDB イン・アクションのほうが量も多いしいろいろ深い。この本はアプリケーションエンジニア向けで、インアクションのほうはDBAまで対象にしてる感じ。

インストールまわりは終わらせていたので、内容としては

  • 基本的なMongo shellの操作
  • import / export
  • インデックス
  • Ruby(Sinatra)アプリからのアクセス

というところが触れられていてよい。

また、

  • バックアップ・リストア
  • Replicaset
  • シャーディング

は付録でちゃんと触れている。必要になれば調べられるように、ちゃんと紹介されていてよい。

Sinatraについては写経して動かした。

github.com

誤植がいくらかあったりしたが、なおしつつちゃんと最新のRuby, Sinatra, mongo drverで動いたのでよかった。

  • Ruby: 2.6.2
  • Sinatra: 2.0.5
  • Mongo Driver: 2.9.0
  • MongoDB: 3.2.22

ソースコードGitHub公開だったら誤植PR送るけど光学社ページからのDLなので挫折。

おわりに

こっちはlocalのruby / sinatraで動かして、MongoDBは chaspy/vagrant-mongodb を使えた。べんり。一応mongoのhostとportは環境変数から取るようにした。

github.com

やっぱSinatraはいいな。

VagrantでMongoDB Replica Setを作る

はじめに

作った。

github.com

いろいろMongoDBをガチャガチャ動かしたくて、まぁDockerで動かすのも普通にできたが、どうせだしReplicaSetも作ろうと思ったので組んだ。

存在は知っていたものの、今回はじめてVagrantのGuest/Hostのhostsを自動設定してくれるやつを使った。

github.com

guestのhostsはこんな感じになる。

vagrant@mongo0:~$ cat /etc/hosts
127.0.0.1   localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost   ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
127.0.1.1   mongo0  mongo0

## vagrant-hostmanager-start
192.168.33.202  mongo2

192.168.33.201  mongo1

192.168.33.200  mongo0

## vagrant-hostmanager-end

Vagrantfileにはこのへんの設定が必要。

  config.hostmanager.enabled = true
  config.hostmanager.manage_host = true
  config.hostmanager.ignore_private_ip = false
  config.hostmanager.include_offline = false

mongodbのreplicasetのinitiate処理だけは全部終わってから、特定の1台であてなきゃならんので別の処理とした。mongo shellのコマンドをどうやってbash scriptから渡したもんかなと思ったが、普通に標準入力で渡してやればいい。

vagrant@mongo0:~$ cat /vagrant/repl.js | mongo
$ cat repl.js
rs.initiate()
rs.add('mongo1:27017')
rs.add('mongo2:27017')
rs.status()
cfg = rs.conf()
cfg.members[2].hidden = true
cfg.members[2].priority = 0
rs.reconfig(cfg)

mongo shellにわたすものなので # でコメントが書けない。 jsなんで // で書けばいいんだろうけど。

おわりに

おもちゃができたのでガンガン遊んでいく。

MongoDB In Actionの2nd Editionが出ていて買ったので、Wired Tigerの章読んで何か書くかも。

www.manning.com

しかしいつになってもVagrantは好きだ。。。こわして作る、再現性があるのがいい。

入社してから1年

たった。シュッと書く。

前回

blog.chaspy.me

まだ1年しか経っていないのか、と思うぐらい成長したと思うし、もう1年も経ってしまったのかと思うほど足りてない部分も山ほどある。

必死になってた最初の3ヶ月過ぎて、半年ぐらいのときが一番しんどかった。すごく時間がかかってしまった。願うならもう二度と同じ体験をしたくない。もしまた転職することがあればこうならないようにしたいけど、まだ答えは見つかっていない。

半年を過ぎて、年明けぐらいからいろいろ新しいことをはじめたりして、ようやくバリューが出せはじめた気がする。

残念ながら英語力は対してあがっていない。先日の海外カンファレンス参加で、やっぱり英語でその場で理解したり、英語でネットワーキングしたり、質疑をしたりする英語力がないとダメだ、と強く思い、具体的な目標もできたのでようやく重い腰をあげてちゃんと努力しようと思う。具体的には でspeakingをVersantで継続的に計測しつつ、カンファレンスの動画を聴いて技術と英語同時にやるしかないなといった感じ。技術も英語も同時に伸ばすの、個別にやってたんじゃ無理だ。

技術力はどうなんだろうな。パフォーマンスについての考え方、AWSの理解、nginx、terraform、kubernetesに関しては仕事で使ってるので嫌でも詳しくなった。ただどうしてもコードを書く量が絶対的に足りてないのを趣味コードでちょいちょいやりつつどうしたもんかなと言った感じ。

多分このあたりはOSSのcontributionで実利をかねてやるのがいい気がしていて、自分で使うツールだけじゃなくて、普段から業務で使ってるOSSへのcontributionもちゃんとやっていかないと、とn年前から言っているが未だにできていない。とりあえずTerraformからやってみようと思っている。

terraform-jp.connpass.com

英語だろうが技術だろうがとにかく思うことは、時間は有限で学ぶべきことは無限にある。このあたりの取捨選択を今まで以上にちゃんと考えないといけないと思う。で結局英語力の問題に帰ってくるのだけれど、書籍はもう日本語ではなく英語書籍から学ぶ、あるいは書籍が出る前に公式ドキュメントを見て動かす、ぐらいが当たり前にならないとダメだ。優秀なエンジニアはこれを当たり前にできている。

環境といえば、やっぱり「環境がひとを変える」とか「一番のへたくそであれ」とか、言葉ではわかっていたことを実際に体験したことが大きい。優秀なエンジニアが多いので、自分の価値観も引っ張られるし、扱う技術に関しても自然とインプットが増える。SREは幸運にも全サービスに横断的に関わるので、目にする技術も多い。(だからこそどこまで学ぶかを迷うのではあるが)

この1年を見返すと、「まぁまぁたいていの仕事は1人でできるようになった」「改善や新しい仕組みの導入もできた」「オンボーディングやExperience mapなどチーム視点での取組もできた」でまぁ60点といったところだ。

次の1年の課題としては、まだまだ不足してる英語力。多めの英文を読むのは今でも時間がかかるし、書くのもまだまだツールに頼っている。リスニングは基本的に一発で聞き取れない。せっかく非日本語ネイティブのロビーが同じオフィスに来たので、さっき言った海外カンファレンスでの収穫を得るためにも、仕事をもっと高いアウトプットを出すためにも、当たり前に必須なので計画立てて継続的にやっていく。

コーディングスキル。これはちょっとどうしたらいいのか、なにが足りてないのかまだうまく分析できていない。一般的な考え方なのか、あるいは言語の学び方なのか、そして何を目標とするかもまだ漠然としているので別でしっかり考えたい。。。

もう1つはチーム視点で、SREもこれからまた少しサイズが増えていくのでチームのことをあれこれするのも少しずつやっていきたい。採用活動も含めて。

あと、ソーシャルやコミュニティ活動を通して、この1年で知り合いがめちゃくちゃ増えた気がする。元々お祭りごとは好きなので、勉強会のたぐいは好きだ。ただ、参加するだけでは得られるものも少ないので、基本的に何かしらの発表をするか、「ちょうどこれを知りたいと思っていた」みたいな技術情報を得られるものでない限りはあまり行かないようにしていた。結局、自分の技術力は仕事を通して得るべきで、ただ話聞いて懇親会で話すだけでは技術力は一切伸びないから仕事をしていたほうがマシだ。

僕はソフトウェアの世界のコミュニティが大好きだ。学生時代から個人が書いたブログにすごいお世話になってきたからアウトプットをしようと思ったし、前職時代に勉強会に参加して、いまSREをやれてるから、自分も運営をしようと思った。この世界に少しでも恩返しがしたい。

SRE Loungeで大き目なイベントをやれたらいいなと思っているので、そっちも楽しみにしつつ、自分もしっかり仕事をして、その仕事の成果を登壇してアウトプットしていこうと思う。

まわりのひとが変わると、自分の「当たり前」が変わる。変わったよ。総じて、転職してよかったと思う。

次は「入社して1年半」でまた書こう。2年にしようかと思ったけど、半年ぐらいでまた振り返っておきたいから。

海外カンファレンスで話すということ

まだ何も終わっていないしなんなら準備もまだなんだけども。恐怖とか不安とかを逃避しようとしているのがよくわかるね。 たくさんフィードバックをもらって、スライド構成を見直して、不要なところをカットしたり新しい具体的な例を追加したりした。

20分。何か1つ、誰かたった1人に伝わればそれでいいと思うし、それが別に海外だろうがなかろうが、勉強会のLTだろうが同じ。 経験したことを共有する、ただそれだけなんだよなぁと言い聞かせるも、緊張するものはする。

昨日はSpeaker Receptionで、日本から参加される藤田さんと合流して参加した。 そのとき思ったことを書き留めておく。

最初は席がなくて藤田さんと2人席で話していたところに、ChairのFrancesが来てくれて、挨拶をしてあっちのテーブルに行きなよと促してくれた。 会場はびっくりするほどノイジーで、静かな場所ですら英語を聞き取れないのに、いわんや、といった状況だった。

それでも、みんな本当にいいやつらで、この記事であと何度言うんだろうって感じだが、それは国内でも海外でも規模関係なく同じだ。 何を話すんだい、あなたは?どこからきたの?はじめて?そういった、絶対に誰にでもするであろう会話だけでも、 自分がここにいることを認められた気がしてホッとした。

見に行きたいな、って思いでメモしておく。話したひとたち。

A Tale of Two Postmortems: A Human Factors View Wednesday, 9:10 am–9:55 am Tanner Lund, Microsoft

Availability—Thinking beyond 9s | USENIX

Jason Wik, Jayan Kuttagupthan, and Shubham Patil, VMware

The MTTR Chronicles: Evolution of SRE Self Service Operations Platform | USENIX

VMwareの彼らとはセッション同じ時間じゃんw という話をした。聴けないのが残念だ。

How to Ruin an SRE-Dev Relationship in 3 Simple Steps Raushaniya Maksudova, Google

Our Practices of Delegating Ownership in Microservices World Daisuke Fujita, Mercari, Inc.

Error Budgets in Banks—Challenges & Way Forward Chaitanya Gorrepati and Alex Titlynanov

Lightning Talks | USENIX

Googleの彼女は、私たちが大きなカンファレンスで、あるいは英語(海外)での発表がはじめてだという話をすると、「Sugoidesu」と言ってのけて、Sugoidesuはあなただよなぁという話をした。東京には何度か来ているようだ。

ちなみに Lightning Talks は事前にスライド提出が義務付けられており、1枚15秒 * 20枚スライドで、自動再生されるらしい。ペースが調整できないのはそれはまた別のテクニックが要求されて厳しい。時間を厳密に守るためとはいえ。

強く思ったことは、強くなってまたここに(厳密に同じSRECon Asiaという意味ではなく、海外カンファレンスという意味で)帰ってきたいということだ。

英語はやっぱり全然聞き取れないし、会話をちゃんとできたとは全然言えないが、それでも自分が話したことを汲み取ってくれて、同じ空間を同じ立場で共有できたことを、嬉しく思った。 怠惰な自分の大きなスタート地点だな、と思った。参加して本当に良かった。

英語できるようになりたいなあなんてことを言ってる場合じゃないや。

とまだはじまってすらないが、1日目の朝食をホテルで取りながらこの文章を書いている。 終わったあとはまた別の感想を持つのだろうか。それはまたあとで書こう。

Speaker Reception のあとはメルカリのみなさんにご一緒させていただきお世話になりました。 これもまたいい経験だった。

さぁ、あとちょっと頑張ろう。

etcd clusterをVagrantで立ち上げる

はじめに

立ち上げた。

github.com

vagrant upしてサービス起動すればいいようにはなっている。

coreosにしたかったがboxが見つからなかったのでubuntuにした。

雑記

  • systemdの設定ファイル内で環境変数を使うために EnvironmentFile でファイル指定した。IPが違うのでそれはinit処理でいれておくことで対処した。
[Unit]
Description=etcd key-value store
Documentation=https://github.com/etcd-io/etcd
After=network.target

[Service]
User=etcd
Type=notify
Environment=ETCD_DATA_DIR=/var/lib/etcd
Environment=ETCD_NAME=%m
EnvironmentFile=/etc/default/etcd
ExecStart=/usr/local/bin/etcd --name ${ETCD_NAME} --data-dir /var/lib/etcd --initial-advertise-peer-urls http://${ETCD_HOST_IP}:2380 --listen-peer-urls http://${ETCD_HOST_IP}:2380 --listen-client-urls http://${ETCD_HOST_IP}:2379,http://127.0.0.1:2379 --advertise-client-urls http://${ETCD_HOST_IP}:2379 --initial-cluster-token etcd-cluster-1 --initial-cluster etcd0=http://192.168.33.200:2380,etcd1=http://192.168.33.201:2380,etcd2=http://192.168.33.202:2380 --initial-cluster-state new
Restart=always
RestartSec=10s
LimitNOFILE=40000

[Install]
WantedBy=multi-user.target
  • systemdのファイル内で改行ってどうするの?ExecStartを改行したい。。。
  • 最初の1台目をスタートするとき、他のホストが立ち上がっていない場合起動に失敗するため、init処理ではサービス起動を行わず、3台立ち上がったあとにコマンドでスタートするようにしたが、なんとかならないのか。
  • ubuntu、ドキュメントにそって手動でインストールしたけどaptで入ることにあとで気づいた、がまぁsystemdファイルいじりたかったしいいか。。。
  • ちゃんと1台でvalue setしたりremoveしたら他でも反映された。すごい。

今後

  • Raftの概要と動きを学んで動かす。このへんか。

raft.github.io

  • なんらかの言語のクライアントライブラリがあればそれ使って動かしてみる。実際に使いたくなるときに使えるように。

  • 2台が落ちたときの復旧方法・動作を確認しておく。1台になるとunhealthyで書き込めなくなるはず。

  • 3台落ちたときの復旧方法・動作を確認しておく。1台だけあげようとすると他がいないのであがらないような気も?(timeout時間内に他もあがろうとすると仲間をみつけてあがるような挙動にみえる。これもraftの仕様を学べばわかるか)
  • データのバックアップ、リストア方法について。データディレクトリをコピってそのままそこにおけばそれだけで復元するのか、どうなのか。
  • etcdctlでできること見ておく

「ソフトウェア開発者採用ガイド」を読んだ

はじめに

読んだ。

ソフトウェア開発者採用ガイド

ソフトウェア開発者採用ガイド

買ったきっかけはもう忘れてしまった。たぶん誰かがすすめてたか記事で書いてたかしたんだろうと思う。速度でポチるからな。

背景

Quipperではほとんどのエンジニアがなにかしらの形で採用活動に関わることになる。自分と働く仲間は自分で探すといった具合で、採用プロセスに関わることになる。例外なく僕もSREの採用プロセスに関与している。

現在も Senior SRE のポジションをopenしている。

career.quipper.com

まぁ何が言いたいかというと採用活動は難しいし、しんどい。ソフトウェアエンジニアがいきなり(効果的な)採用担当にはなれず、採用活動には何かしらの知識なのか、方法なのかがある。というわけで読んでみた。

いくつかドッグイヤーをつけていた部分を抜粋してみたい。

決断には2種類の答えしかない。採用か、不採用かだ。(p93)

これは kyanny さんが確かどこかにissueで言及していたのが心に残っている。結論には PASS か FAILの2択しかないし、自分は PASS を一度言い渡しながら、その後のプロセスにどうの言うのも違う。

本書にある通り、「採用してもいいけど、私のチーム以外に」もNGだ。

このあたりはわりと採用活動に関わる初期の段階で意識できたので、苦しまずに済んだと思う。

また、これはまたどこかで kechol さんが言っていたけれど、偽陽性を避けているという話をしていた。これもこの本に書いてあったとおりだ。

優秀なひとを逃すことももちろん惜しいが、優秀でないひとを採用してしまうほうが恐ろしいということだ。

迷うというか、積極的に ( QuipperではPASS か FAIL かの判定に Positive か Negative か2択を出す ) Positive が出せないのであれば、それは Negative なのだ。それが早い段階でわからなかったらもっと苦しんでいたかもしれない。

誰を採用すべきかをどうやって判断するかということだ(p95)

原理的にはいたって簡単だ。あなたが探す人というのは

  1. 頭が良く
  2. 物事を成し遂げる

頭の良さを面接で推し量ることは難しいし、それを知るための、(一見ソフトウェアエンジニアリング、募集するポジションに関係ない)質問をするつもりにはなかなかなれない。ただ、後者の「物事を成し遂げる」という点は自分も見ていると思う。

CV、あるいは面接での会話から、技術力を測るために、技術的に何を成し遂げたか、その過程でどういう思考をしたのかはよく尋ねているように思う。

面接のイントロダクションは候補者をリラックスさせるためのものだ。(p100)

できるだけ相手に力を発揮してほしいとは思うし、人当たりというものは意識しているが、リラックスさせることはまだできていないと思うので、改善したい。挨拶をして、今日の流れや目的などを説明することは相手をリラックスさせることに少しは効果があるとしても。

良いプログラマはすべて再帰とポインタを扱えるべきである(p108)

これは採用プロセスがどうのとか自分への学びというより単に興味深かった。確かに大学時代ポインタである程度のひとが挫折していく。ポインタが理解できることは才能であると言い切る本書の発言は面白かった。

しかし「最後にソートアルゴリズムを書いたのはいつのことですか?」という質問には自分もドキッとしてしまう。

おわりに

この本に書いてある内容は若干古い内容でありつつも、参考になる部分は多く、Quipperの採用プロセスにたずさわるエンジニアも読んでいるひとが多いように思う。そういう意味では共通認識が得られてよかったと思う。

あとは ohbarye さんが hiring support の haruka-oisoさんに、採用観点でエンジニアが読んでおいてほしいと思う本はなんですか?と質問していて、 Work Rules と回答していた。当然 ohbarye さんたちはこれを読んで採用プロセスの改善等行っているわけだが、僕はまだ読めてないので次はそれを読みたい。

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

で、会社のslackチャンネル眺めてたらやっぱり ohbarye さんが読んでたからなのでした。ちゃんちゃん。

ohbarye.hatenablog.jp

ディスカッション中心のイベントSRE Sessionを開催しました

はじめに

開催しました!

sre-lounge.connpass.com

SRE Loungeという、各社SREが取組を共有する、プレゼンテーションメインの勉強会があります。これはこれで貴重な知見がたくさんあるのですが、やはり全員参加で、相互交流ができる会も欲しくなってしまいました。また、SREといっても扱う範囲は非常に多岐に渡るため、特定のテーマにしぼって語り合う会をやりたい!と思い、言い出しっぺに法則で立ち上げました。

テーマ選定

SRE Lounge Slackでアンケートを取った上位2テーマを選択しました。

f:id:take_she12:20190415130148p:plain:w300

(Public Chennelのものなので特にふせずにそのまま載せてます)

項目の元ネタはSRE 1st Book / Workbookから僕が適当にかいつまんだものです。

2テーマじゃなくて1テーマでもいいんじゃないか、と迷いましたが、実験的な会だったので読めなかったのと、幸運にもSLOとMonitoringはかなり関連性が強いということもあって2テーマでGoしました

イデア

実はこの会はCloud Native Deep Diveからインスパイアされたものです。

www.meetup.com

実際、私は#4のMonitoring編に参加してこのイベントのやり方のヒントももらったりして非常に感謝しています。

Cloud Nativeの文脈とSREの文脈は、参加者層が微妙に違うような気がしつつも、共通する部分は非常に多いので、今後とも良いシナジーを出せたらいいなぁと思ってます!

公開後1番乗りでDeepDive主催の @jacopen さんが熱い思いで参加申し込みしてくれて嬉しかったですw

Welcome Talk

各テーマごとに、会場を温めることと、語彙の共有、トークのネタとしてWelcome Talkを話していただきました!

YahooのtsukaさんよりSLO

www.slideshare.net

「誰のためのSLOか?」の一言につきます。この言葉はディスカッションでも多く話されたと思います。

メルカリspesnovaさんよりMonitoring

内容が盛りだくさんで後半巻いてもらったのがもったいないぐらい(再演をどこかで!)濃度がぎっしりの資料でした。RED & USEの考え方ははじめて知ったので非常に参考になりました。

ディスカッション

多いに盛り上がり、司会&タイムキーパーの僕も熱中して時間がすぎてしまうほど(反省)。

それぞれ20分じゃ足りない感じだったので今後の改善につなげていきたいと思います。

感想

概ね多くのひとからも好意的なフィードバックをいただいており、本当にやってよかったと思います。

SRE本に書いている内容をどの会社も実践できているわけではなく、そのレベルや考え方も様々。それをディスカッションすることで良い点悪い点を議論し、今後のみなさんの実務に結びつく機会になっていれば幸いです。

振り返りと今後

事後アンケートを実施し、たくさんのフィードバックをいただきました。参加者のみなさんありがとうございました。

みなさんのフィードバックのおかげで、次回開催も決定しました!次回は6/5に開催を予定しています。(会場まで決定しており、準備中)

プレゼン形式のSRE Loungeと毎月交互でやっていきたいと思っているので今後もよろしくおねがいします!

最後に会場提供してくれたQuipper... のhiring-supportのみなさんとSRE @motobrewさんお手伝いいただきありがとうございました、この場を借りてお礼申し上げます。