双六工場日誌

平凡な日常を淡々と綴ります。

スマホからガラケーに変えて連絡先がうまく移行できなかったので、Googleの連絡先をガラケーの電話帳に変換するスクリプトを書いた。

先日、ブログにも書いた通り、SIMフリースマホのZTE Blade Vec 4Gを買って、これまでスマホでやっていたことはおおよそそちらに移行を済ませました。

最近話題のSIMフリースマホ「ZTE Blade Vec 4G」を買って、一週間使ってみた。 - 双六工場日誌

結果、これまで使っていたスマホでは、音声電話とメール、おサイフケータイぐらいになったので、これまでのスマホ回線はauのガラケー「Gratina」に機種変更。

f:id:sechiro:20141102194709j:plain

左がBefore、右がAfter。

機種変更はあっという間でおサイフケータイの移行もすんなりすみましたが、地味に引っかかったのが電話帳の移行。スマホからガラケーに変える人で同じようなことにハマる人も多いと思うので、移行の際に使ったスクリプトとメモを書いておきます。

続きを読む

Strata + Hadoop World 2014 in NYC に参加してきた。

2014/10/15-17の日程で開催された「Strata + Hadoop World 2014」に参加してきたので、見たセッションとざっくりとした感想をメモ。

発表者の録画ビデオやスライドはこちらにあるので、詳細が知りたい方はこちらへ。現時点では、スライドやビデオがないセッションも結構ありますが。

今回Strata + Hadoop Worldのセッションは、以下のテーマにわかれていました。

  • Business & Industry
  • Data Science
  • Data-Driven Business Day
  • Design & Interfaces
  • Hadoop & Beyond
  • Hadoop in Action
  • Hadoop Platform
  • Hardcore Data Science
  • Law, Ethics & Open Data
  • Security

この中で、自分に取って新鮮だったテーマは「Law, Ethics & Open Data」。２日目のClouderaのChief TechnologistのEli Collins さんのお話などは、このテーマ、ド直球のお話で示唆に富んでいたと思います。

聞いていないセッションの方が多いので、全体は把握しきれないところがありますが、全体的な印象としては事例紹介では単純なHadoop導入事例はなくなって、具体的なビジネスでのデータ分析の活用を中心としたセッションにシフトし、技術的なセッションでは、機械学習など高度分析や処理基盤全体アーキテクチャ、Spark等の新しいプロダクト紹介など、より高度なものが多くなっているように思いました。

個別プロダクトでは、Spark関連のセッションが多く、かつ、どれも人が多く集まっていて関心の高さを感じさせました。YARNの活用事例*1は、Tez + Hiveが注目されていましたね。

自分が参加したセッション

自分が参加したセッションは以下のものです。面白そうなものが多かったので、体がひとつしかないのが悔やまれます。

1日目（午後から）

2日目

3日目

個別のものは、とても感想が書ききれないので、取り急ぎ、見たものリストのみで。

追記

そういえば、ミュージカルを見た後に締めのラーメンを食べようと思って、ニューヨークの一風堂に行ったら激混みでラーメンを食べそこねました。。。

f:id:sechiro:20141024002454j:plain

*1:SparkはYARN上でも動かせますが、一旦別扱いで

最近話題のSIMフリースマホ「ZTE Blade Vec 4G」を買って、一週間使ってみた。

最近、MVNOのSIMが複数リリースされ、それを使うためのSIMフリー端末も充実してきたように思います。僕もその流行に乗って「ZTE Blade Vec 4G」を購入してみたので、簡単に使用レポートを書いてみます。

f:id:sechiro:20141004150137j:plain

写真: 開封の儀の様子

購入の経緯

これまでは、auの回線でHTC Jを使っていました。厳密に言うと、まだこの端末も併用しているので、使っていたというのは語弊がありますが、今はこちらのスマホはほとんど使っていません。鞄から出すのは、おサイフ携帯機能使うときぐらい。

HTC Jに機種変更したのは、ちょうど2年前。3Gのみ対応でLTEは使えない機種です。ただ、IS03からの機種変更だったので、当時はさくさく動くことに感動した記憶があります。

ただ、この機種はアプリをインストールできる領域に制約があり、最近ではその制約のためにアプリのアップデートが止まることもしばしば。また、常駐しているアプリが増えてくると、プチフリーズみたいに操作が固まったり、電池がすぐに切れてしまったりと、そのほかにもいろいろつらみが溜まっていました。

仕方がないので機種変更を検討。当初はHTCの最新機種、HTC J butterfly HTL23への機種変更も検討したのですが、月々の支払いが高くなるので躊躇していました。良いイヤホンがついてきたり、スペック的な魅力はあるんですが、自分の場合はAndroidで音楽を聞くことはないので、いろいろオーバースペックなんですよね。

また、SIMロックされている端末だと海外に行った時に格安の現地のSIMが使えないんですよね。旅行中、同行者とLINEで連絡を取ることが多いのですが、現地SIMなら1000円以下で済むところが、現地で使えるWi-Fiをレンタルするか国際ローミングをするとなると、数千円の出費。海外に行った際には、着信用にはメイン回線が必要ですが、ガンガン使うにはやはり現地SIMを入れたSIMフリー端末がベスト。

こういう上でSIMフリー端末を調べてみて、たまたまキャンペーンで特別価格になっていた「ZTE Blade Vec 4G」の購入を決めました。

続きを読む

AWS CLIで最新のAmazon LinuxのAMI IDを取得する

アニメを消化しつつ、コマンドラインから最新のAMI IDを取得を試して、Amazon Linuxの分はできたのでメモ。

ID取得からインスタンスの作成まで一発でやってしまおうと思ったけど、describe-imagesはAPIのレスポンスが遅かったので、とりあえず、一覧だけ出力するところまで作成。APIのレスポンスが遅いのは、キャッシュファイルを入れて緩和。

最後に載せているスクリプトは、キャッシュファイル対応のために長くなっていますが、本質的なポイントは以下の２つ。

自分とamazonがオーナーになっているAMIのうち、以下に該当するものを取得

  • 仮想化方式　→　HVM（完全仮想化）
  • 起動ディスク　→　EBS
  • アーキテクチャ　→　x86-64
  • ボリュームタイプ　→　磁気ディスク(standard)
aws ec2 describe-images \
    --owners self amazon \
    --filters \
      Name=virtualization-type,Values=hvm \
      Name=root-device-type,Values=ebs \
      Name=architecture,Values=x86_64 \
      Name=block-device-mapping.volume-type,Values=standard

取得したJSONをjqで以下のように整形

  • Imageのリストを名前順にソート
  • Platformが"windows"となっているものを除外（Platformは値が"windows"のみしかない属性）
  • NameとImageId（AMI ID）を文字列結合して出力
jq -r '.Images | sort_by(.Name)| .[] | select(.Platform != "windows") | .Name + ": " + .ImageId'

これらをまとめて一つのスクリプトにしたのが以下。ほかの条件でAMI IDを取得したい場合は、最後に参考文献に載せたドキュメントを見つつ改変してください。

続きを読む

自分が訪れた香港は、世界中から人と物と歴史が流れ込む混沌とした美しい街だった

ここ最近、香港で大規模デモが起きていて、デモの写真や映像を見ることが多いのですが、ちょうどそのデモが始まる一週間前の連休に、その香港の街を旅行してきました。

自分が見た香港は、世界各国からいろんな人や物が流れ込んでくる混沌とした街で、一方、中国の伝統文化も併せ持つ魅力的な街でした。

デモのニュースだと、そういったところはなかなか出てこないので、自分が印象に残った場所を写真で紹介したいと思います。あくまで自分の旅の非常に個人的な記録で、観光客がスマホで取った旅行写真ではありますが、香港に興味を持つ人が増えるきっかけになれば。

ちなみに、最近、羽田ー香港間のLCC「香港エクスプレス」の直通便が出ていて、自分たちが行った時は燃料サーチャージ込で往復40,300円ぽっきりの格安価格で羽田から直接香港に行くことができました。チケットの取り方にも寄りますが、国内便に乗るような感覚。ただ、早朝便で時間が早くて、始発では間に合わない可能性が高かったので、前日に羽田の「First Cabin」に宿泊。早朝便は使い勝手は微妙ではありますが、着いたら一日フルに使えるのがメリットです。

出発前

これが前日泊した羽田の「First Cabin」の個室。

f:id:sechiro:20140920003832j:plain

香港到着後

ここから香港の写真。これは、香港空港から都市部に移動するバスの中で取ったもの。これが「Docker」ですね。まさにアジアの流通拠点という感じ。

f:id:sechiro:20140920112310j:plain

f:id:sechiro:20140920112442j:plain

行く途中にはイオンもありました（真ん中の赤紫の看板）。日本では見られない、超高層ビルを背負ったやたら強そうなイオン。

f:id:sechiro:20140920112640j:plain

続きを読む

クックパッドの新オフィスでitamaeによる寿司の無限プロビジョニングを体験して、Ansibleのお悩み相談してきた #infra_sushi

今日は、クックパッドの新オフィスで「Infrastructure as Code 現状確認会」があり、運良く繰り上がれたので参加してきました。

新オフィスは、恵比寿ガーデンプレイスタワーというおしゃれスポットで、オフィスにはキッチン付きのスペースがあって、そのキッチンではその寿司が無限プロビジョニングされているという夢のような空間でした。

f:id:sechiro:20141003194157j:plain

写真：無限プロビジョニングされる寿司

本編終了後のLT枠が空いているとのことだったので、本編の間に資料を作ってLTもしてきました。内容は昨日つぶやいた最近のお悩み相談。最近、AWS + Ansibleの環境で実現方法に困ったことを2つ紹介して、相談させてもらいました。

資料はこれ。

そして、これがお悩み相談に対する会場でのベストアンサー。

ですよねー(´；ω；｀)

お悩みの詳細はスライドを見てもらうとして、一つのツールですべて賄おうとして頑張ってしまうと、構成に矛盾が出てしまうので、適材適所で組み合わせて使わないといけないというのは、完全に正論。

自分の中では、この問題は根本的にはインフラをどう抽象化・モデル化して、コードに落とすかというところにも関わる問題で、試行錯誤していたところをバッサリやってもらったので、だいぶInfrastructure as Codeへの理解が深まった気がしました。

手抜きをしてしまいたいがために、ツールが向いていないところまで無理やりはめてしまって、あとから拡張性やメンテナンス性に限界が来て死ぬというのは、よくやってしまう失敗なので、つらみが出たら、根本的にアプローチが間違っていないか見なおした方がいいですね。。。

会場でのツイートはTogetterにまとまっているのでこちらから。

本編の内容

本編のスライドで見つけたものを貼っておきます。

構成管理ツールととしては、"Chef"とクックパッドで開発されている軽量Chefの"itamae"、"Ansible"が話題に上がっていました。ちなみに会場シェア的には、Chefはほぼすべての人の手が上がっていて、Ansibleは半分ぐらいという感じ。構成管理ツール以外では、あらゆるインフラをDSLでCode化してしまうお話とServerspac/SpecInfraのライブV2リリース。

自分では構成管理ツールにAnsibleを使っているのですが、インフラをコードに落とすという観点では、やはりChefは完成度の高いツールだと思うので、そのエッセンスだけ抜いてできることを限定して、学習コストを下げたitamaeは良さげな感じでした。

また、@さんの発表でも「Chefは、Rubyで何でもできますよ、言われると…」みたいな話があったと思うのですが、自由度が高いっていうのは諸刃の剣で、なんでも書けるためにあとでメンテがつらくなったり属人化しやすくなったりしてしまうので、その点ではitamaeやAnsibleのようにできることが限定されているのは、自分の環境では逆にメリットになっているように思います。

Infrastructure as Codeは、あらゆるシステムの常識になるぐらい流行って欲しいので、そのためにももう少し自分の中で経験を貯めてどこかで発表したいですねー

クックパッドのみなさんには、ISUCON予選に引き続き、またお世話になりました。お寿司大変美味しかったです。ごちそうさまでした(・∀・)

それではこの辺で。

2014/10/05 追記

このお悩み相談について、Ansible本の筆者の@r_rudiさんから回答ブログをいただき、それに関わるやりとりをしたのでまとめました。

そちらをみてもらえると、こういう問題に対するAnsibleでの解決策がわかるので、合わせてお読みください。

回答ブログはこちら。

Ansibleでの連番ホスト名をつけるなど — そこはかとなく書くよん。

それに関連するやりとりのまとめはこちら。

AWS + Ansibleのお悩み相談についてのやりとり - Togetterまとめ

ちなみに、Ansible本はこちら。

Amazon.co.jp： 入門Ansible eBook: 若山史郎: Kindleストア

ISUCON 4にチーム「ヤキトリ缶（タレ）」で参加したが、いまいちパッとしない感じだった #isucon

先週開催されたISUCON4に、去年に引き続き参加してきました。

チームメンバーは去年と同じ@と@。チーム名は、去年に引き続きチームミーティングした時に目の前にあった食べ物です。ちなみに去年のチーム名は「勝浦タンタンメン」。

参加日は1日目、仕様言語は去年に引き続いてPython。Goが有利みたいな高度な情報戦も流れていたのですが、去年、Pythonで勝てなかった悔しさから今年もPythonで再挑戦と決めていので、特に言語選択では迷いませんでした。

結果

結果から言うと、タイトルの通りいまいちパッとしない感じで、予選時に提出したスコアは30000弱。予選1日目からベンチマークに見直しがかかったので、更新後のBenchmark v2で、後日確認したスコアはだいたい35000。最終結果の発表は、10/6（月）なのでまだわかりませんが、予選通過ラインには届かなさそうな気配。

今回やったこと

今回やれたこと／やろうとしてやりきれなかったことをざっくり。

  • やれたこと
    • login_logテーブルのインデックス追加: 3000 → 10000ぐらい
    • usersテーブルへのip, last_loginの追加: 10000 → 25000ぐらい
    • index.htmlの静的ファイル化とNginxからの静的配信 → 2000ぐらいアップ？
    • インフラ側はポート枯渇に対応するカーネルパラメータの設定とかNginx-gunicorn間の通信をUnixドメインソケットにするなど、動作に必要な設定のみ。
/etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 10000 65535
  • やりきれなかったこと
    • lock_user, banned_ipのロジック改善
      • アプリ上では、ログイン失敗数をカウントするところまでできてはいたんですが、初期データの反映が間に合わず、提出は断念。
    • ミドルウェアのチューニング
      • MySQLを5.5 -> 5.6 入れ替えたつもりだったけど、提出AMIはそうなっていなかった。。。そのほか、最後、アプリの実装が間に合わなさそうと見切りをつけて、こっちをやっていればもう1, 2割はなんとかなったかも。

前回のISUCON3の予選では、結果として予選の環境とベンチマークに特化したスコア稼ぎで予選を突破してしまった*1ので、今回は普通のチューニングで着実にスコアを上げていく方向で進めたのですが、いろいろ手間取っているうちにタイムアップ。

飛び道具には手を付けず、とはいえ、超絶アプリ改修もなしの至って普通のチューニングです。

自分たちのチームではこの程度のチューニングができれば予選は通過できると踏んでいたのですが、フタを開けてみると今年は去年以上にレベルが上がっていて、4万以上のハイスコアを出すチームが多数。その勝負の舞台に乗りきれなかった感じです。この辺りの読みと判断も含めてISUCONの勝負なんですよね。。。

当日までの流れ

対策ミーティング

僕たちのチームメンバーは、会社もバラバラで一緒に開発した経験もないため、去年のISUCON本戦ではお互いのやっていることがバッティングしたり、開発方針を共有したりするのに手間取ったので、一旦メンバーで集まって、去年のISUCON予選の問題を題材にして、チーム開発の方法を確認。実質的にはGithubハンズオンで、Mergeリクエストベースで開発することを決めて手順確認。

参加者ブログを見ると、1台のサーバ上のファイルを書き換えたという侠気あふれる報告もありますが、それができるのはいつも一緒に作業してて、阿吽の呼吸があるからだと思うんですよねー

なので、一手間かかりますが、Mergeリクエストを送って、各人が編集内容を確認できるようにしました。

去年のISUCONブログを見ても、役割分担を完全に決めてしまって、それぞれの作業は見ないで進めたって話がほとんどなんですが、即席チームだとなかなかそうも行かず。

本当はもっと対策ミーティングをやったり、ミドルウェア系の秘伝のタレを用意したりしたかったのですが、結局なかなか集まる時間を取ることができず、ISUCONがあった週は自分が毎日終電を逃すスパイラルに陥っていたので、最低限の開発手順と視点の共有ぐらいの準備で本番に臨みました。

当日の流れ

当日の流れを箇条書きで。

  • まずはAMIを起動して、アプリ確認。銀行アプリかと見せかけたログインするだけのアプリ。
  • ベンチマークを掛けてみる。MySQLの負荷が高い。
  • 開発環境として、メンバーごとにインスタンスを作成。

  • リポジトリの作り方をミスって作り直したりしてて30分ぐらいロス。立ち上がりに時間がかかる。

  • 午後一でアプリを読んだ結果を共有

    • login_logをなめて、ユーザの最終ログイン時間、ロックユーザ、BAN IPを取ってる
    • login_logを最後になめてレポートを作ってて、それがこけるとスコアが登録されない
    • login_logにはINDEXが貼られていない
    • usersテーブルは一切更新されない（初期ユーザのみ）
    • 去年引き続き、1台のサーバにベンチマークが共存しているので、Nginxで返したり、インメモリアプリ化による高速化が効きそうな作り。
    • 自分は一旦、通常のWebアプリとしてのチューニングを実施し、ほかのメンバーがインメモリ化を検討する方向に。
  • 最終ログイン時間とログイン失敗数は、usersテーブルに書いておけばlogin_logを舐める必要はない
  • banned_ipはip管理用のテーブルを追加すればよさそう。（これは最後まで実装間に合わず）
  • 最終的には使わない予定だけど、login_logを舐めるのがヒドいので、とりあえずINDEX貼る
CREATE INDEX id_idx_1 ON login_log (ip, id);
CREATE INDEX id_idx_2 ON login_log (user_id, id);

-> これだけで3000 -> 10000〜までスコアアップ

  • login_logも初期データがあって、最終ログイン時刻とログイン失敗回数はそのデータを反映する必要がありそう。
  • @に、awkワンライナーで最終ログイン時刻一覧を作ってもらって、最終ログイン時刻だけ反映するSQLを作成
  • usersテーブルに最終ログイン時刻とIPを追加して、ログイン時にアップデートするよう変更。
  • 最終ログイン時刻と最終ログインIPの仕様を誤解して、手間取る。
  • ここまでの改修で20000を超えるようになったが、ポート枯渇などのエラーが出るので、カーネルパラメータを変更し、Nginxとgunicorn間の通信をUnixドメインソケットに変更。
  • このタイミングでMySQLを5.6に変更。skip-innodb-doublewrite、innodb_flush_method = O_DIRECT_NO_FSYNC までなら通常の永続化は保たれてセーフだと踏んで設定。これでちょっとスコアアップ。
    • ただ、最終提出AMIへの反映が漏れていたことが、あとで発覚。
  • 続いて、ログイン失敗回数をusersテーブルに書き込むようアプリを改修。
  • @に、awkワンライナーでユーザ・IP別のログイン失敗回数一覧を作ってもらう。
  • ただ時間が迫ってきているのに焦って、ログイン失敗書き込みが漏れてFail。泥罠的な修正を加えたため、バグを埋め込んでしまい手間取る。
  • ベンチマークはFailなしで走るようになったが、初期データの反映ができていないため、レポートで落ちる。。。
  • 結局、安定した時点までのアプリでベンチマークが通ることを確認して時間終了。

以上。

こうしてまとめて見てみると、大したことができてなくてつらい(´；ω；｀)

大したことないアプリの改修で、舞台に飲まれてバグを埋め込んで時間を使いすぎました。。。

去年の本戦でも感じましたが、こういった時にすぐに解決策が出てこなかったり、コードを修正するのに手間取ったりするのは、普段からの修行不足。

もう予選も終わり、予選用のリポジトリも公開設定に変更したので、恥ずかしながら、使ったリポジトリのURLを貼っておきます。華々しい結果ではありませんが、ISUCONアンチパターンとして見ていただければ。

予選は双六工場こと、僕の自宅から参加したのですが、うちの周りから上野に掛けてIngressのポータルが多いので、予選後は反省Ingress会をやり、上野の「もつ焼き　大統領」でもつとか馬刺しとか食べて解散。

まとめ

振り返って見ると、いろいろ反省点はありますが、判断ミスややりきれなかったところも含めて、今の自分の実力とも思うので、 予選自体にはそんなに悔いはないです。あとはなにかの奇跡が起こって、運良く本戦に引っかかることを祈るのみ。

ISUCONは、すべての参加者が同じ土俵で戦ってベンチマークスコアのみで勝敗が決まる単純さが面白いですね。非常にわかりやすい。なんとなく、幽遊白書の魔界トーナメントを思い出します。やっぱりこういうお祭りがあると、盛り上がるし、エンジニアの実力がこうやって可視化されるのは、間接的にはIT業界全体にとってもいい影響を与えているのではないかと思います。個人的にも、こういう機会があると普段の仕事の時にも気合が入ります。

最後になりますが、運営のみなさま、出題を引き受けてくれたクックパッドのみなさまに感謝を。貴重な機会をいただき、ありがとうございました。毎年規模が拡大し、参加者にもノウハウが溜まってくる中でISUCONを運営するのは、非常に大変だと思いますが、それが続けられているのも、歴代の運営スタップが真剣に取り組んでくれているからだと思います。予選運営お疲れさまでした。

予選通過は厳しい感じではありますが、いずれにせよ本戦が楽しみです。10/6の最終結果発表を楽しみにしつつ、今日はここまでで。

*1:前回も意図したものじゃなくて、チューニングとして意味がありそうなものを順番に試していったら、うまくいくポイントを見つけてしまったというのが実情なんですが