収録時間: 47:56 | Download MP3 (29.1MB)
江島健太郎さんをゲストに迎えて Macbook, 開発環境, Rails, Heroku, VPS などについて話しました。
kenn: いやなんか、すごい人気みたいですね。
miyagawa: 人気だね。
kenn: いきなりランキングの上の方に行ったとか。トップ10とかに入ったんじゃないかな。
miyagawa: 実際の数は FeedBurner で出てる数がけっこう日によって前後するからわからないんだけど、まあ500〜1000の間ぐらいらしくて。でも iTunes にのったのは1日、2日経ってからだから。
kenn: ちょっと反映が遅いよね。でもその前の、iTunes にのせる前のやつがカウントされてないとかいう話もあったよね。
miyagawa: それもあるかもしれない。Apple の iTunes と iOS の Podcast アプリがどういう風に統計情報を iTunes のサーバーに送っているのかがよくわからないから、その前の分ももしかしたらカウントされてるのかもしれないけど。
kenn: Subscribe すればダウンロードでカウントしてるっていうことかな。
miyagawa: その可能性もあるよね。
kenn: でもやっぱりいいよね。ああいうのに出てくると。
miyagawa: ちょっと嬉しいね。
kenn: ちょっとびっくりするけどね。
miyagawa: びっくりする。
01:10
kenn: アジェンダは、わりと開発寄りっていうか。
miyagawa: そうだね。一応そういう Podcast っていうことにしてるから(笑)
最近は MacBook Pro Retina 使ってるの?
kenn: そうそう、Retina ですよ。Retina いいよ。かわいいよ。
miyagawa: 15inch?
kenn: 15inch。
miyagawa: 重くないですか。
kenn: 重くないよ。今まで分厚い方の 15inch ずっと使ってたから、それからすると、そもそも薄くなった上にすべてがグレードアップして。もう文句なしにいいね。
miyagawa: 13inch はまだ駄目かね。
kenn: なんかグラフィックが駄目みたいね。Intel の組み込みのやつ使ってるでしょ。Retina の解像度にそもそも性能が追いついてないんじゃないか説があって。
miyagawa: だよね。でもこの間ちょっと、CPU とか上がってるじゃん。
kenn: 微妙にアップグレードしてたけど、結局 GPU のところは変わってなかったんじゃなかったっけ。まあ来年か、今年あたりにもう一回メジャーバージョンアップしたぐらいに 13inch 買いどきじゃないかな。え、買い換えるの?
miyagawa: いや Air の Retina みたいのが、それが今の 13 なのかもしれないけど、そういう感じのやつが出たらいいかなって思ってるけどね。
kenn: たぶんこれはしばらく Pro で行くんじゃないかと思うけどね。そこの差別化にするんじゃないかな。
miyagawa: やっぱりそうだよね。
kenn: いまだに 15inch のやつでも Retina じゃないやつを残してたりするじゃん。それを買ってるかわいそうな人もいるし(笑)
miyagawa: あれはなんで残ってるんだろうね。
kenn: ねえ、意味わからないんだけど。とっとと無くして Retina にした方がいいと思うんだけど。
miyagawa: でもあれが一番売れてるって Apple は言ってるじゃん。Pro の13inch が一番売れてるって。
kenn: へえ。それはちょっと意外だな。ダントツで嫌だと思っていたけど(笑)バランス的に言うとね。
3:07
miyagawa: MacBook で開発するときって、家と外では違うんでしょ。
kenn: そうなんだよね。ウチは家は iMac の 27inch を使ってて、カフェとかに行ったときに Retina を持ち出してる感じだね。
miyagawa: ぼくは Air の 13inch で、家でも外でもメインはそっちなんだけど。使い分けるのって、たとえばラップトップ上で Rails とかで開発するときとかって、ちょっと面倒くさくないですか? というのが気になってたんだけど。
kenn: でも環境を構築するのって、けっこう慣れるよ。俺けっこう昔から2台でやる体制でやってきてるから、環境をゼロからセットアップするのがすごい速いのね。手順書みたいのがあって。それもだんだん手順書に書いてあることもすごい少なくなってきて、暗記出来るレベルになってきたんだけど(笑)
ほとんど Dropbox とか、SkyDrive とかあるじゃん。ああいうやつでファイルは共有して。ソースは Git に全部あるし、デカいファイルは ARFS っていう P2P でデカいファイルでも無限に送れるっていう……ほらCubbyが駄目になっちゃったから、それに乗り換えたんだけど。そういうのでもファイルを同期しちゃえば、ほとんど困ることはないかな。
miyagawa: 最初にインストールするときっていうのはたしかに手順があって、大体慣れてくればっていうのはあるんだけど、たとえばカフェでちょっとやってて、いいところで一回家に帰らなきゃいけないときとかに、まだ家のマシンにそれが100%シンクしてない可能性もあるじゃん。
kenn: git push して帰るっていうのじゃ駄目なの?
miyagawa: なるほどね。でもそうしたら、家のマシンで git pull しなきゃ駄目なわけだよね。
kenn: それはしなきゃいけないね。だから git push/pull のワークフローだよね。
miyagawa: Dropbox じゃなくて、一回 Git を経由する方法の方がいいっていうこと?
kenn: コードに関しては全部 Git だね。
miyagawa: テンポラリのログファイルを見たいときとかあるじゃん。
kenn: そういうのは Dropbox かな。かなり便利になったよ、そういう意味では。道具が揃ってきたおかげで。だから MacBook に関してはほとんど使ってるフォルダがなくて、ドキュメントフォルダはほとんど空みたいな。ほとんどが Dropbox とスカイドライブと ARFS だけに入っていて、ようはシンクされないファイルはもうない、みたいな感じ。あとは GitHub のローカルコピーぐらいかな。
miyagawa: まあ、それが正しい感じがするけど……でもオフラインで開発するときとか、たまにあるわけよ。どうしても。
kenn: それは Git でいいんじゃないの。
miyagawa: だけどオフラインで終わった後、自分のマシンに持っていくたびに……
kenn: それはプッシュしないと(笑)
miyagawa: まあね。一応1台だと、そういうのを考えなくていいのかなって。
kenn: でも壊れたときに困るよ、それは。
miyagawa: そうなんだよね。一応バックアップはしているわけだけど、たしかにスイッチしなくていいメリットがある分の不安感は、一個のマシンにいろんなローカルに依存したものが入って汚れていく、みたいなのはあるよね。
kenn: それもあるし、もう一個あるのは、Mac ってけっこう生命線じゃん。俺らの生活にとって。片方壊れてもバックアップがあるっていうのはけっこう心強くて。こっちが壊れてる間はこっちを使う、みたいな感じにできるから。わりと安心感っていう意味では大きいかな。
あと、iMac の方は母艦にしてて。ハードディスクのサイズもでかいじゃん。だからここからバックアップサービスとかに繋いでて。クラッシュプランっていうやつに入ってるんだけど、ここにあるやつはオフサイトバックアップが取られてる、みたいな感じ。みやんはあれ使ってたよね。
miyagawa: Mac mini かな。そこから Arq っていうソフトで S3 と Glacier にでかいファイルはコピーしてるっていう感じ。
kenn: おお、Glacier ね。なんか最先端な感じがするよね。
miyagawa: そうね。でもあんまり自分で API 書かないでソフト使ってるのがちょっとしょぼいけど。
kenn: Arq って GUI のソフトだよね。いいよね。
miyagawa: そうそう。一応スクリプトも付いてるみたい。コマンドラインのバックアップツールもあるみたいだよ。
kenn: ということは、それを使えばカスタマイズ的なこともできるってこと?
miyagawa: できないこともないんじゃないかな。
kenn: もしくはクローン的な。
miyagawa: そうだね。結局その会社で安心感があるところがあるとすれば、フォーマットがプロプライエタリというか、ただのファイルじゃなくて、一回エンクリプトした後に、かつバージョン管理みたいなこともしてるから、S3 に入ってるファイルの実体は、元々のファイルの実体とはちょっと違うものが入っていて、そうするとその会社がつぶれたらどうするんだっていうのが懸念点だから、一応オープンソースで取り出すツールは GitHub で公開していて。だから、万が一その会社が買収されたとか潰れたとかしても大丈夫みたいな。
kenn: 会社が無くなっても、誰かが復旧する方法を考えてくれるだろうっていう期待ができると。でも Glacier って、取り出すのが面倒くさいんじゃなかったっけ。
miyagawa: 入れるのは S3 に入れた後に何十日経ったら Glacier に移す、みたいなのをやると一番簡単みたいだね。もしアプリケーションとかから自分が使いたいときがあったとした場合は。
kenn: それはちなみに、取り出すときは逆の操作で出すの?
miyagawa: そうみたい。取り出すときは、S3 に戻してっていう API コールをすると、何時間後かにテープから復旧されて、S3 のバケットに入ってるから、それを取り出すんじゃない?
kenn: ああ、それを待てばいいだけなんだ。じゃあ S3 を操作するっていう体験自体は変わらないんだ。
miyagawa: だと思ったけどね。自分でやったわけじゃないけど、そういう記事を読んだよ。
kenn: ああ、それだったらいいかな。値段はすごい安いからさ。
miyagawa: 安い安い。今 150GB の写真のローファイルを全部入れて、それでも月に1ドルとか。
kenn: 150ってすごいね(笑)そんなにあるのか。
miyagawa: S3 だったら10倍ぐらいするから。
kenn: そうだよね。っていうか S3 高いよね。
miyagawa: 高い。保存するだけだったら S3 馬鹿みたいに高いよ。
kenn: しかも取り出す帯域代がさらに高いという。なかなか上手い囲い込みで(笑)
miyagawa: そう、入れるのは安いんだけど、取るときに高いっていう。
kenn: 行きは良い良い、帰りは怖いモデルで。
miyagawa: 上手いモデルなんだけどね。
kenn: まあビジネスとしてはそうなるんだろうけど。
9:26
miyagawa: マシンのセットアップの話題で、GitHub が今週 Boxenっていうツールを公開していて。見てないかな。
kenn: 見てないな。最近ちょっとニュースが追えてない。
miyagawa: https://boxen.github.com/ にあるんだけど、これはちょうど半年ぐらい前に GitHub の IT の人がプレゼンしていて。The Setup っていう風に社内では呼んでたみたいなんだけど、GitHub って今 150人ぐらい従業員がいて、みんな基本的に機能的には同じ環境を使っていて。MacBook で。サーバーとか開発環境だけじゃなくて、実際のマシン、ローカルのラップトップ自体も、みんな同じ標準的なセットアップしているらしくて、それを自動化するために Puppet を使っているらしいんだよね。
kenn: Puppet なんだ、へえ。
miyagawa: で、それを内製でいろいろカスタマイズしたものを作っていたんだけど、これをオープンソースでどの会社でも使えるようにしたっていうのを出してるみたい。
kenn: なるほど。カッコイイね、このページ。
miyagawa: 開発用の Ruby とか Node とかから始まって、MySQL ももちろんそうだし、あとは冗談なのかわからないけどマインクラフトとか、あとは IRC のツールとかTwitter クライアントとか、そういうのも全部 Puppet の中に入ってて。
kenn: マインクラフトって(笑)
miyagawa: ゲームじゃんって感じだけど。
kenn: やる気あんのかって。
miyagawa: それも全部標準的なセットアップがあって、あとは個人の好みによって変えたいところはカスタマイズスクリプトでする、みたいな。みんなでやってるって書いてあった。
kenn: そうか。やっぱり開発環境を揃えるのってけっこう課題だよね、本当に。
miyagawa: ぼくの今の会社もインストールツールはあるんだよね。何もないまっさらな状態から、Ruby を入れて Homebrew 入れて、MySQL とか Node とか、必要なものを全部入れてっていうのは全部スクリプトになってるかな。
kenn: そうなんだ。そういうのスクリプトにした方がいいのかな……ウチは未だにさっき言ったような手順書みたいな形になってて。RVM 入れて、とか書いてあるのをひと通りやると、一応環境は出来上がる、みたいなレベルかな。
あとはまあ、サーバーサイドのエンジニアとクライアントサイドのエンジニアで必要なものが違いすぎるっていうのもあって。
miyagawa: まあ、多少違うのはあるよね。
kenn: Xbox と Unity で開発するっていう人たちはほとんどサーバーサイドのものは入れなくてよかったりするので。そこら辺の統一感のなさがあるのかもしれないな。
なんかその開発環境っていう意味で rails-dev-box っていうのがあったよね。
miyagawa: あったね。あれって、インストーラーみたいな感じなのかな?
kenn: インストーラーなのかな。Vagrant だったと思うけど。
miyagawa: なるほどね。VirtualBox。
kenn: Vagrant で、仮想環境の中で開発のための環境を整備するみたいな考え方なのかな。
miyagawa: やっぱりでも Rails とか、先週のエピソードでも話したんだけど、MacBook で開発するっていうのが元々、DHH とかはみんなやっていたから、そういうのがすごくやりやすいのはあるけど、だんだんカオスになってきてるから。
初心者の人とかが……初心者である必要はないのかもしれないけど、むしろ上級者の方がカスタマイズとかいろいろしてて、他の環境と共存しにくい、みたいのもあるかもしれないよね。
kenn: たしかにね。けっこう決め打ちのデフォルトとかあるよね、いろいろ。想定的なものが。ベストプラクティスから外れたことをやろうとすると途端に大変になる。ていうか、Rails って初心者にはやさしくはないよね。
miyagawa: そうなんだよ。そこをすごく思ってて。初心者に優しいかどうかっていうより、いいことがあるとすれば、困ったときに決めなくていいっていうのがあるじゃん。もし Sinatra で1つ作ろうとなったら、データベースは何にしようとか、ORM 何にしようとか、ロガーは何にしようとか、まずファイルのレイアウトから決めなきゃいけないじゃん。どこのディレクトリに何を置いて、とか。そういうのが決まってるのはいいなって。
kenn: Rails is お任せだからね(笑)
miyagawa: DHH が書いてたのは、寿司屋に行って、わざわざわさびの量とか言わないだろ? みたいな。
kenn: ごちゃごちゃ言わないでお任せにしとけ、と。
miyagawa: だけど、お任せっていうより寿司ナチみたいな感じがあるから。
kenn: 寿司ナチ(笑)言われとるよね。まあ、間違ってないわな。
miyagawa: DHH の好みが強すぎる、みたいな感じが若干あるけど。
kenn: 超頑固親父だから。まあ、自分で言ってるぐらいだからね、Opinionated って。頑固親父の言うことを聞かないと怒鳴られるっていう。怖い寿司屋みたいな感じ。
miyagawa: 一応でも、それを使わない選択肢っていうのもあるじゃん。たとえばテストに Rspec を使うとか。元々はデフォルトじゃないけど。あと ERB がたぶんデフォルトだけど、Haml にするとか。そういうのはいろいろ、gem を入れればとりあえず動くから。そういう意味での自由度は多少あるとは思うんだけどね。
kenn: まあ、そうね。だから Rails が想定してる標準と、みんなが使ってる標準との乖離が激しいっていうだけで(笑)そこだけだろうな。
miyagawa: そこ迷うよね。ぼくの知り合いの元 Perl 使いの人がこの間 Rails を始めて、Twitter とかブログでさんざん愚痴というかいろいろ書いてて。RSpec とか FactoryGirl とかいろいろテストのために入れていくんだけど、学習コストが大きすぎて、しかも Rails ガイドにはそれ全然書いてないし。
kenn: 書いてないからね(笑)そんなものはさもないことであるかのように。たぶんあれだよね、流行みたいなものが標準ガイドだと追えないっていうのがやっぱり大きいよね。 FactoryGirl とか Rspec みたいなものってある意味流行的な側面もあるじゃん。
miyagawa: たしかに。
kenn: 俺はいまだに RSpec ってあんまりいいと思ってないというか。いつも、こんなこと言うと怒られるんだけど(笑)
miyagawa: ぼくも最初は、初めて1週間ぐらいは何だこれって思ってたけどね。
kenn: 文句言ってたよね。いまやむしろ advocate になってるんじゃないの。
miyagawa: そんなことはないけど(笑)良さはわかるようになった。だけど、いつも Rspec がtest-miniとかよりいいかって言われると、場合によるんじゃないかなとは思うけど。
kenn: そうだよね。というか、無意味に学習コストを要求してるところが大きいよね。あまり本質的じゃないところで。そういうところで初心者がつまづくポイントを用意するのはすごくもったいない気がしてて。
miyagawa: たしかに 3.いくつの Asset Pipeline とか、すごくいいものだっていうのはわかるけど、Heroku にデプロイすると絶対エラーが出るとか。それで絶対 FAQ見るんだけど。なんかね。
kenn: あれは厳しいよね。 Asset Pipeline は相当厳しいよね（笑）Heroku はまだマシな方で、自分のサーバーにデプロイしようと思うと確実にコケまくる感じなので。あれはすごくアレルギーを作っている気がする。
miyagawa: 去年の RailsConf に行ったんだけど、DHH のキーノートは、喩え話的なので、子供向けのおもちゃのトースターがたとえばあって、実際には何もトーストされないんだけど、入れると出来上がったパンが出てくるみたいなオモチャがあったとして、でもそういうので勉強しても、実際の料理をできるようにはならないと。だから Rails はオモチャじゃなくて、最初からリアルな体験をしなきゃいけないっていう意味では……
kenn: 箱庭じゃねーぞと。
miyagawa: 学習曲線がそういうところにあるのは、そういうものなんだと。そういう風に言っていたけどね。たぶんそういう意味では、「初心者にやさしい」とは誰も言ってないんじゃないの、Rails 自体はっていう。
kenn: たしかに(笑)まあ、そういう割り切りはありだと思うけどね……ていうか、Rails の話でいいんだっけ。
miyagawa: いや全然いいよ。全然 OK だと思う。
18:00
miyagawa: Rails は去年の年末から今年にかけて、すごい脆弱性がバンバン見つかったよね。
kenn: ああ、いっぱい出て、あれはすごい困ったよね。
miyagawa: 何なんだろう?
kenn: 何だろうね。やっぱりあれじゃない? eval は良くないっていうことなんじゃない(笑)
miyagawa: ちょっとメタプログラミングしすぎとか。
kenn: そういうのでやっぱり脆弱性が入り込む余地が大きすぎるみたいな。
miyagawa: ひとくちに脆弱性って言っても、けっこういろんなパターンがあったよね。一番大きいのは yaml のやつだけど。yaml って元々、設定ファイルっていうよりも、最初は Perl の Storable とか Ruby の Marshal みたいなもののプレーンテキスト版で、ヒューマンリーダブルなオブジェクトシリアライゼーションで、物によっては、ベーシックな、プリミティブなクラスだったら言語間での互換性というかインタープライオリビリティもあるよ、みたいなフォーマットだったのが、だんだん設定ファイルより便利じゃね? って話になって、次はもうデータシリアライズだから、もうネットワーク、REST で……
kenn: ああ、その辺からだね。
miyagawa: JSON とかと一緒に使えばいいんじゃね? みたいな感じになってたのがたぶん問題だよね。
kenn: そうだね、その最後のやつが問題だよね。
miyagawa: で、だから結局、リクエストのところに yaml で、アクティブリレーションのクエリのオブジェクトを突っ込むと、インジェクトできちゃうとか。
kenn: まあクラスをインスタンスにできちゃう時点で、もう何でもありになっちゃってるって話だよね。なんかあの、safe_yaml だっけ。
miyagawa: あった、あった。
kenn: そういうのができないようにして、本当に JSON の別シンタックスみたいな。そういうのに割り切ってしまおう、みたいな考え方はありだと思うけどね。設定ファイルだとそれでいいし。
miyagawa: そういう使い方しかしないならね、そっちのほうが、安全側に倒すっていうなら。Python の yaml は safe_load っていうのがデフォルトに入ってるから、大体普通はみんなそれを使うようになってるんだよね。
kenn: なるほどね。まあ、それでいい気がするな。
20:25
miyagawa: ここ4〜5年ぐらい、MySQL ですごくダムな入れ物、賢くない入れ物として使うようなことをけっこうやってたりして。ようは MySQL にはインデックスだけ入れて、データはブログでシリアライズして、みたいな。今言ったような話とかやってて。フレンドフィードがそういうことやっててさ。
kenn: ああ、そうだったかもね。
miyagawa: これいいなって思ってみんな、KVS が流行ってきたっていうのもあったから。
kenn: MySQL を KVS として使うみたいな。
miyagawa: そうそう。そういう使い方って一瞬流行った感じがあって。でも PostgreSQL の HStoreはすごくいいなって思うよね。バランスがすごく取れてるというか。
kenn: そうだね。セレクト文でちゃんとハッシュのキーを指定して取り出すみたいなこともできるし、あとインデックスも貼れるよね。素晴らしい。
miyagawa: PostgreSOL は使ってないでしょ、でも。
kenn: プロダクションレベルで使ってるやつはないね。今作ってるやつはあるけど。
miyagawa: MySQL も新しいのが出たから。
kenn: 5.6か。あれもまた素晴らしいよ。
miyagawa: どこが素晴らしいの?
kenn: 一番大きいのはたぶん、大きい規模にならないと関係ないかもしれないけど、フェイルオーバーがやっとできるようになる。
miyagawa: デプリケーションして?
kenn: そう。マスターとスレーブに分けておいて、マスターが落ちたときにその処理をスレーブに引き継ぐみたいな。そういうのってけっこう面倒くさかったりしたんだけど、それが MongoDB 的な、わりと自動で検知してあっち側に倒すみたいなことがしやすくなるっていうのと、あとトランザクションごとにグローバルな ID が付くようになって、どっちが先に進んでるか、みたいなことをあんまり意識しなくてもよくなったというか。だからスレーブもコピー作るのも簡単になるし。HAセットアップっていうのかね、セットアップがやりやすくなるっていうのかな。
でも結局、クライアント側が対応してくれないとあんまり嬉しくないっていうか。マスターとスレーブの両方に接続を張っておいてくれないと、クライアントが。今の Ruby とかだと、ドライバがそういう風に作られているやつがないので、そのメリットを享受できるまでっていうのはまだ先っていう気もするけど、その道が開かれるっていうことかな。
miyagawa: 今の話だと、運用面の改善が多い感じだね。
kenn: そうだね。速度が早くなるとか、Join が速くなるとか。どっちかといえば地味な。
あれだね、NoSQL とか言い出してからみんな頑張るようになったよね(笑)
miyagawa: そうそう、Postgres のやつもそうだし、MySQL もね。そういうプレッシャーが出てきたからね。
kenn: 外部からの脅威にさらされて(笑)やる気になってきたような。
miyagawa: やっと使いやすくなってきたか、みたいな。
kenn: ほんとにここ数年でかなりデータベースは良くなったと思うよ。それまでの進歩はかなり遅かったんだけど。みやんは Redis 使ってるよね。
miyagawa: Redis けっこう使ってる。
kenn: あれはいいよね。
miyagawa: Redis はすごくいいと思う。
kenn: あれの良さがあんまり、とくに日本の界隈で認知されてない気がするのは何でなんだろう?
miyagawa: どの辺がいいんだろうね。
kenn: なんか……便利じゃん(笑)
miyagawa: ぼくが思うのは、Redis ってすごくアルゴリズムにぴったりハマりやすいっていうか。MySQL とかってどうしてもリレーショナルデータベースだし、それに頭を合わせなきゃいけない感じがするじゃん。 こういうアルゴリズムを組みたい、で、このデータを保存したいっていうのに、いちいち RDB で考え直さなきゃいけない。だけど Redis は集合を作りたければセットがあるし、リストを作りたければリストがあるし、ハッシュを作りたければキーバリューがあるし。
kenn: そうか、じゃあプログラミング言語に近いんだ。
miyagawa: そうなんだよね。プログラミング言語のネイティブの型をそのまま保存できるような気がするのが、何となく気持ちいいところかなっていう。
kenn: たしかにそれはある。もっと使われてもいいような気がするんだけどな。
miyagawa: あとは単純に、ツール的な話で言うと、なんだっけ。setnxとかいう、ロック作るのにすごく便利。kenn の gem があったけどさ。
kenn: はいはい。redis-mutex みたいな。
miyagawa: あれを複数の環境でロックするのに便利かなって。
kenn: 共有する資源を。そうなんだよね。ある意味グローバル変数として使える感じだよね。
miyagawa: そうなんだよね。だから memechached とかと一緒なんだけど、キャッシュって、名前にキャッシュっていうのがあるからボラタイルな感じなんだけど、Redis っていうのはもうちょっと永続性があるグローバル変数みたいな。
kenn: ちゃんと使えるものっていう感じがするよね。勝手に消えないものみたいな。
miyagawa: memechached っていうのは、あってもなくても使えなきゃいけないものっていう気がするんだけど。
kenn: Redis は本当にビジネスロジックの中に入ってくるものっていう感じがするよね。なんかもう、これなしで物を作れる気がしないんだけど(笑)
miyagawa: でも Redis だけではないんでしょ。Redis と Mongo とか、Redis と MySQL とか。
kenn: そうだね。だから本当にこれはグローバル変数として使う感じで。どのプロジェクトにもついてくる、みたいな。DB は MongoDB かもしれないし、Postgres かもしれないし、MySQL かもしれないけど、Redis は必ず使う、みたいな感じだよね。逆にだから memechached は使わなくなったよね。
miyagawa: キャッシュはしないの?
kenn: キャッシュが必要なときにするけど、でもあんまりキャッシュしなくてもよくなってきたっていうことない? 最近。性能良くなってきて。
miyagawa: ん〜、わからん。やっぱり使うときはかなり使ってると思う、かなり。
kenn: たぶんね、あまり HTML のレンダリングをしなくなったからかもしれない。API とかで JSON ジェネレートして渡すだけとかだと、サイズもすごい小さいじゃん。だから memechached に頼るレベルでもなくなってきたっていうか。CPU のコストもすごく安いし。
たぶんその辺のトレンドの変化が影響してるのかもしれない。だから俺は実際、もう今やってるプロジェクトほとんど API だし。HTML のレンダリングやってるのはあんまりないな。…… Lingr ぐらいじゃないかな(笑)
miyagawa: でも Lingr もコメットだから、レンダリングも JSON とかじゃないの? サーバーサイドでやってるか、最初は。
kenn: 最初はサーバーサイドでやってるね。
miyagawa: でもチャットのメッセージは……
kenn: そうそう、JSON でやってるから。そうなんだよね。だからキャッシュ使ってないよ。あ、使ってるか。最初の読み込みの部分、30件とかだけは memechached 入れてるけど、それ以外では使ってないし。だんだん要件が変わってくるにつれて、使う道具が変わってきたなっていう感じはある。
miyagawa: まあキャッシュは相変わらず使うけどね。インデックス的なものを作るときとか、アーカイブとかさ。マンスリーアーカイブの件数を出すときとか。絶対変わらないのに、すごく SQL が重くなるようなときとか。
kenn: ああ、そういうのってでも、ストアしてしまわない?
miyagawa: そういうやり方もあると思う。
kenn: そういう必ず使うものはロジカルにちゃんと表現して、
miyagawa: 埋めちゃうっていうことね。キャッシュじゃなくて。それもありかもね。
kenn: ある意味 RDB の正規化の延長上にあるというか。そういう発想でやってるかな。
28:15
miyagawa: さっきなんか、Heroku の話が出たから。Heroku ちょっと今週、炎上してるよね。
kenn: 炎上してるね(笑)ちょっとかわいそうになるけど。
miyagawa: これは、"Heroku's Ugly Secret" っていうブログのポストがあって。この人は Heroku の一個前のヴァージョンというのかな。Bamboo っていうスタックでずっと開発していたんだけど、で、毎月いくらだったかな、かなりの額だったよね。2万ドルだったかな。払って、すごく Dyno、Heroku の Dyno っていうのはインスタンスのことなんだけど、すごくいっぱい立ち上げてパフォーマンスを出していたんだけど、だんだん遅くなってきてて、しかも問題が、New Relic を使ってるんだけど、 New Relic がレポートしているメトリックと Heroku がレポートしてるメトリックが全然ずれてて。
kenn: 一致しないと。
miyagawa: これは Heroku がちょっと騙してるんじゃないか、みたいなことを書いたら……
kenn: 稼ぐために性能落としてるんじゃねえの、と(笑)
miyagawa: 次の日に釈明のポストが出て、これは結局、 Bamboo のときっていうのは 1Dyno 1プロセスで、1リクエストしか同時にさばけないっていう前提があって、それをスケールさせるためにフロントにロードバランサを自分で作って、空いているインスタンスを探すっていうのを入れたんだけども、Cedar っていうのを新しく作るときに、一個のサーバーで同時に複数をさばくこともあるから、わざわざ空いてるのを探すのをやめて、もう全部ランダムにしちゃえと。そういう風に変えたみたいなんですよね。
そうすると、Bamboo だと一個しかさばけないのが、ランダムにすると、まだ動いているのにそこにどんどんキューされていって、速いリクエストはすぐさばけるんだけど、遅いのは何秒も待たされて、みたいな。そういうことがあったみたいですね。
kenn: そうだね。すごい遅くなるっていう話だったよね。50倍ぐらいのコストがかかるみたいな。
miyagawa: 結局、資源がどうとかっていうことより単純にロードバランサがちゃんと動いてなかったっていう話なんだろうけどね。
kenn: あれ、ロードバランサがちゃんと動いてなかったんだっけ? ランダムに割り振られるとレスポンスのバラつきがけっこうあったので、遅いやつに積まれる確率が非常に高くなったというか、そんな感じだよね。
miyagawa: そんな感じ。一応ページには絵が描いてあって、ルーターが3つあって、2つあるときにどういうふうにさばかれるべきか、みたいなことが書いてあるけど。
ようは結局 Cedar っていう新しいスタックシステムを入れたときに、 Bamboo の方がどんどん遅くなっていったという感じみたいだね。
kenn: あれ、でもその仕組みとは別っていう話だったよね。Cedar は Cedar でランダムのロードバランサに変わったんだけど、文句言ってる人の環境は Bamboo のままだったから、じつはランダムにはなってなかったんだけど、ロードバランサをどんどん追加していったことで、お互いロードバランサ同士では知識を共有してないから、結局ランダムに割り振ってるのと同じような状態になってしまっていた、ということみたいなんだよね。
miyagawa: なるほど。
kenn: 結局ロードバランサが増えると、どんどんランダムになっていく確率は上がるので、性能は落ちるっていうごくごくかわいそうな状況になってる。
miyagawa: 結局 Heroku 側としては、この辺の仕組みを改善するという約束はしているみたいだけど。
kenn: そうだろうね。1アプリ1ロードバランサ、ロンリーロードバランサみたいな感じにしないと解決はできなさそうな感じがする。
でも Heroku 的には、それは気づかないでいてくれた方が、そのままでいた方が稼げたっていうオチで(笑)
miyagawa: これはトランスペアレンシーという意味では、すぐに反応したのはいいのかもしれないけど、言われてからすいませんでしたっていうのは、ちょっとあれだよね。
kenn: New Relic とか使ってるとバレちゃうもんね(笑)ていうか、 New Relic 使ってる?
miyagawa: ぼくはプロダクションとかでは使ってないんだけど、試しに使ってみたりはしてる。
kenn: ぼくは会社でも会社でも個人でも全部使っているんだけど、かなり良くて。遅いクエリのある場所とかっていうのがすごく細かいレベルで、メソッドレベルで絞りこめるので、パフォーマンス・チューニングをするときの良いお供みたいな感じで。無料版もあるから助かるっていう感じだよね。
miyagawa: New Relic の仕組み自体は、アプリケーションのいろんなインストルメントポイントを入れて New Relic のサーバーに送って、それをメトリックスを出すっていう感じだよね。
kenn: 基本はそうなんだけど、ほとんど全自動だから何も設定しなくてもいきなり API キーを入れるだけでいいっていう感じだよね。
miyagawa: そこの落差はいいよね。
kenn: ほとんどみんなが知りたいであろう情報っていうのは勝手に取ってくれてるから。
miyagawa: まあ New Relic 自体が無料で提供してるのは素晴らしいけど、何となくちょっと不安があるというか。
kenn: あ、そうなの?
miyagawa: ほら、まあ潰れたりはしないだろうけど、やっぱりそういう特定のところに依存するのは嫌だなっていうのはあるんだよね。オープンソース版とかないのかなって思ってるんだけど。ないんすかね。
kenn: なんか見た気はするんだけど……でも New Relic でいいじゃん?(笑)タダだし、パフォーマンス・チューニングするときしか必要ないから、無くなっても別に困らないというか。そしたら外せばいいだけ、みたいな。まあ、そのうちもっと良いのが出るのかもしれないけど。でも New Relic 相当儲かってるみたいだから、潰れることもないだろうし。
miyagawa: 何となく一個の会社が出しているものに依存するっていうのがヘルシーじゃないなって、ぼくが個人的に思ってるってだけなんだけど。便利なものは便利なものだから、使えば全然いいんだけど。まったく問題はないんだけどね。
kenn: そう思うんだけどね。とくにタダであれば。
miyagawa: いや、わからない。3年後、4年後、5年後にどうなるかはわからないでしょ。
kenn: まあね。でも、ぼくはもう4年ぐらい使ってるけどな。どんどん機能も追加されたりして、良くなっているし。今のところは信頼できる感じはあるかな。
そういう意味では、サービスにサードパーティのものを使うかどうかって、けっこう重要な意思決定だよね。新しいサービス作るときに。
miyagawa: そうなんだよ。ぼくが前にいた会社は Yコンビネーターのソフトウェアサービスの会社だから、むしろバンバン使え、みたいな感じで。
kenn: YC系のやつはガンガン使え、みたいな。
miyagawa: むしろ自分でメール送信とかそんなものまで全部作るな、みたいな感じで。それはすごい良かったよね。だけどやっぱり、そういうのが難しい規模とか会社のポリシーっていうのはあると思うから。
kenn: たしかに意思決定が難しいときはあるよね。アーキテクチャに関わってくる部分じゃん、サービスの。そこで単なる技術的な側面だけじゃなくて、コストどれぐらいかかるの? とか、そういうレベルの話になってくると巻き込む人が増えるから、意思決定に時間がかかっちゃったりするよね。
miyagawa: たぶんプロトタイプとかならそういうのもバンバン使えばいいと思うけど。本質的じゃないところにそういうのを使うのは全然ありだと思うのね。たとえばメールを送信するとか、メールのエラーを受け取って何かをするとかって、自分の会社のコアコンピタンスがメールサービスじゃないかぎりは、そんなところに開発リソースを割いてもしょうがないわけじゃん。だけど、たとえば動画の紹介をするサービスをやってるときに、動画のエンコーディングを Amazon とかにアウトソースするのが果たしていいのか、とかはあるから。
kenn: たしかにね。
miyagawa: そこら辺の判断というか。
kenn: やっぱりコアコンピタンス部分はアウトソースできないんじゃないかな。アウトソースできる状態になってる時点で、コモディティ化してるってことだよね。
miyagawa: たしかに(笑)
kenn: Amazon ができるっていうことは、完全にコモディティの世界だから。ようは Amazon と競争している状態になるわけでしょう。だからその上のレイヤーに行かなきゃ駄目なんだろうね、きっと。
miyagawa: あとは、どれだけロックインされるかっていうか。どれだけスポイルされるかっていうのもあるんだけど、そこを使うことによって、そこのサービスが急に値上げしたときとかにいきなりランニングコストが倍になります、みたいなのとかってあるじゃん。
kenn: あるね。ちなみに今日ちょうど、その New Relic の営業から電話がかかってきて(笑)お前、すげえ安い値段で契約してるけど、そろそろちょっと見直さんか? って言われて。ちょっと人に言えないような値段で New Relic のプロパンを買ってるんですけど、それを4倍ぐらいの値段に値上げされそうになって。「それは勘弁してくれ」って言って……やっぱり、アメリカっていう国は戦わないと駄目ですね。
miyagawa: そんなところで(笑)
kenn: エネルギーを浪費してるのかもしれないけど。
miyagawa: そういう恐怖があるわけじゃん? やっぱり。
kenn: それで言うとさ、インフラの下に行くほど怖いよね。だからぼくは Heroku とかけっこう怖いんだよね。GoogleAppEngine がまさにそうだったじゃない? いきなりすごい値上げして、みんなエグソダス状態になって(笑)
だから、Heroku もじわじわ価格が相対的に上がっていってたっていうのもそうだし、下のレイヤーを握られるのが怖いっていうのはあるよね。
miyagawa: ただ、これは Heroku のいいところでもあり悪いところでもあるかもしれないけど、Herokuはあまりプロプライエタリな技術を使ってないじゃない。Heroku 向けに何か特別な。もちろん、さっき言った Asset Pipeline とか、バッドノウハウ的に、Heroku だからこうしなきゃいけないっていうのも多少あるとは思うんだけど、Heroku でしか使えないコードっていうのはあんまりないかなと思って。
たとえば GoogleAppEngine とかだと、GoogleAppEngine の API を使って書いたら、もう外に出すことはできないわけじゃない。そういうのがあまりないのは、使う側にとってはいいかなっていうのはあるよね。
kenn: ということは、Heroku を卒業してオンプレミスとかに移行した人っているのかな。
miyagawa: あるでしょ。というか、前の会社の dotCloud にいたときにぼくが思ったのは、けっこうこういうコモディティな技術を使ってると、卒業するのが簡単になるから。技術を提供するところ以外の、エクスペリエンスっていうのかな、そういうところでいいものを出していかないと、このアプリがデプロイできるからここを選ぶっていうのはもうほとんど意味がないというか。それがどれだけ簡単に、どれだけ低コストで、どれだけ時間かからずにやって、かつそこにデプロイすると、こういうメリットがある、とか。
Heroku の場合は、たとえばアドオンっていう仕組みがあるから、そこら辺がもっと簡単にできるみたいな、そういうメリットがどんどんないとすぐ卒業していっちゃう。さっき言ってたみたいに。という気がしたんだよね。
kenn: なるほどね。いや良い時代ですね、ユーザーにとっては。
miyagawa: そういう競争が起こってくれればすごくいいよね。
kenn: やってる人たちは大変だろうけどね。
40:20
kenn: クックパッドはあれだよね。AWS に移行したっていう。
miyagawa: AWS に移行したのはだいぶ前で、EC2 から VPC っていうバーチャルプライベートクラウドに移行したのが 3ヶ月、4ヶ月ぐらい前かな。
VPC自体は、ページを見ると VPN が張れたりするような、EC2 のすごい版みたいなことが書いてあるんだけど。クックパッドとしてはもちろん、専用線を張ったり、社内から繋げたりっていうこともあるんだけど、基本的には EC2 のすごい版という形で、あと IP アドレスを固定できるとか。そういうメリットの方が大きいから VPC に移行したってことだよね。
kenn: IP は固定してほしいよねえ(笑)
miyagawa: あまり値段も基本的には変わらないみたいだよ、EC2 と。専用線を張ったりすると、かかるんだけど。
kenn: Amazon って一体どれぐらい契約数があるんだろうね。相当あると思うんだけど。
miyagawa: むしろそっちが本業なんじゃないかぐらいのレベルになってきたけどね。
kenn: なってるの? 本当にそんなになってるの? (笑)
miyagawa: わからないけど(笑)見てる感じだと。やっぱり小売業って利益薄いでしょう。
kenn: 利益は薄い。でもその発想をクラウドの方にも持ってきてるよね。利益を還元するというか、けっこうちょこちょこ値下げしてるじゃん。
miyagawa: S3 とか高い高いって言ってるけど、どんどん下がってはいるよね。
kenn: そう、ちょっとずつ値下げしてきてるからね。ああいうところは偉いと思うよね。Amazon の哲学が出てるというか。ただまあ、Amazon だけに規模がでかい分、オペレーションのオーバーヘッドが高いからかわからないけど、基礎コストはちょっと高いんだよね。ぼくとかが見る、すごいケチケチ運用コスト派から見ると、やっぱりかなり割高感があって。
miyagawa: たしかに、ちょっとやってると月20ドル、30ドルかかっちゃうもんね。初期コストが。だから Linode とか、あとこの間見ていた Digital Ocean っていうSSD の VPS 。あれ、いいよね。
kenn: 安い。安いし、本当に速い。
miyagawa: 使ってる?
kenn: うん。もうプロダクションで運用することが決まりました。決めたらサクッと使う。
miyagawa: やっぱり SSD でやるっていうメリットは大きいだろうね。
kenn: そうだね。SSD いいよ。なんか Unicorn …… Unicorn って Rails のサーバーだけど、起動が2秒ぐらいで16個ぐらい上がるっていう。
miyagawa: いいね。
kenn: まじで速い。CPU も速いし。
miyagawa: やっぱりディスクアクセスがめちゃくちゃ速いから、Web サーバーとか置くのがいいのかな。
kenn: 何を置くにもいいと思うよ。データベースももちろん IO バウンドだし。あとディスクのサイズも、SSD だから少ないのかって思ったら、同じ金額の Linode とかと同じぐらいの値段なのでほとんど失うものがない状態。何をやるにもやっぱり速い。
miyagawa: 月10ドルのプランでメモリ1GB、SSD30GB で転送量2TB。
kenn: そう。その追加の転送量も S3 の10分の1ぐらいだよね。
miyagawa: そうだよね。この転送量の安さは何なんだろう?
kenn: なんだろうね。元々タダだったからね、これ。つい1ヶ月前までタダだったのが、さすがにそれだと悪用するやつがいっぱい出てきてサービスが不安定になってたので課金を開始したらしいんだけど、帯域に。
miyagawa: どういう秘密があるんだ?
kenn: わからない。何か裏があるんじゃないかと思っていろいろ調べてたんだけど、少人数で運用してるとか、現代的な構成にするっていうところで差別化してるみたい。仮想化技術も現行世代の中では一番進んでる KVM と、そのバート IO ???ってやつとかを使ってて。日本だとさくらVPS とか、あの辺のやつが最新世代なんだけど、US にある VPS ってけっこう遅れてるんだよね。Linode とか Rackspace とか、EC2 もそうだけどみんな Xen ベースじゃん。ひと世代前だから CPU のオーバーヘッドも大きいし、けっこうかかる基礎コストが大きいんだよね。
だからその辺のイノベーションを早く先取りすることで、過去の資産を抱えてない強みを生かしてるって感じじゃない?
miyagawa: たしかに。ちょっとこれは使ってみようかなと思ってる。今 Linode でいくつかサービスを動かしてるんだけど。
kenn: そういうのは持ってこれるかもね。
miyagawa: この Podcast の mp3 ファイルとか、ホストを置かせてもらってるさくらのサーバーがね、ものすごい古いマシンだから(笑)
kenn: 2002年とかじゃない?
miyagawa: 2004年ぐらいにビルドしたマシンで、よく動いてるなっていう感じだけど。結局、Apache で動かしてたのね。べつに普通なんだけど、けっこうメモリ食うアプリを動かしてるからプロセス数が10とかしか動かせないわけですよ。
で、こいつがポート80で動いていて、Podcast の mp3 配信したら、みんなダウンロードするわけじゃない。そうするとスロットが埋まるわけよ、Apache の。何もしてないんだけど、ただ配信するだけで Apache 全部止まっちゃうっていうことになってて。だからしょうがないから、先週の週末に nginx ビルドして、80番をプロキシして。
kenn: nginx ビルドできたの?(笑)
miyagawa: そう、できたんですよ、これが。感動ものだよ。gcc 2.いくつだからね。PCRE っていう mod_rewrite みたいなやつはビルドできなかった。だからそれを外してビルドしたんだけど。
kenn: それでいいのか(笑)
miyagawa: それ以外はちゃんと動いたから。
kenn: リライトなしの Web サーバー。
miyagawa: まあ、いいんだよ。
kenn: スタティックファイルをサーブするだけっていうことね。
miyagawa: プロキシはできるから、大丈夫。
kenn: nginx はそういうのにすごく向いてるよね。
miyagawa: 向いてる。全然安定して動いてるから。こんなに古いマシンでもちゃんとビルドできるのはすごいなって思ったけどね。
kenn: 素晴らしい。
miyagawa: とはいえ、この Digital Ocean がちゃんと動けば、こっちにいくつか持ってきてもいいかなって思ってるんだけど。
kenn: あとは DreamHost っていう手もあるよ。
miyagawa: DreamHost って、レンサバだよね?
kenn: レンサバだけど、容量無制限、帯域無制限。まあ、もしかしたらキャッチがあるのかもしれないけど。
miyagawa: あると思うよ。転送量無制限のレンサバけっこうあるけど、大体調べると、日に何十GB超えたらスロットル???されます、とか。
kenn: なるほど。だとしたら、こういうところでちゃんと払ったほうがいいのかもしれない。
47:33
miyagawa: そんな感じで、ちょうど1時間になってしまった。かなり濃かったな……会話が。
kenn: いろいろあったね(笑)
miyagawa: ついてこれるのか、聞いてる人が(笑)まあでも、これぐらいがちょうどいいかもしれないけどね。そんな感じですかね。ありがとうございました。
Transcribed by Hiroaki Kadomatsu http://d.hatena.ne.jp/note103