Life with open mind

2013年6月28日金曜日

グリーを退社しました

本日がグリー株式会社での最終出社日でした。実際の退職は月末ですが、事実上もう会社に行くことはありません。 ... 前にパナソニックの退職エントリを書いてから1年ちょっとしか経っていませんが、新しい仕事に挑戦したくなり、退職を決めました。

組み込みエンジニアからWebのインフラエンジニアへの転身という「どうしてこうなった」的なキャリアパスでしたが、コンピュータサイエンスやプログラミングの知識そのものは共通で使えました。カーナビのブートローダーやデバイスドライバを書いた経験なんてどれぐらい役に立つのかなと思っていましたが、案外 Linux のカーネルレベルでの解析やチューニングに携わることが多く、また Apache や PHP も C言語で書かれているので、直接経験が生かされた感じです。本当に幸運でした。でも PHP は結局書けないままです...

働いてみて一番よかったと思ったのが、書籍や勉強会などで積極的に発表している人が身近にいたということです。グリーで働くまでは結構遠い存在のように思っていたのですが、入ってみると隣の机だったりすることがあり、とても良い刺激になりました。また社内での勉強会もあり、仕事に関係があってもなくてもとにかく「学ぶ」ことに意欲的な人が多かったです。

相変わらず女性エンジニアはレア度が高く、これはもう業界にいる限り仕方がないかなという気がします... でもそんな中、以前掲載されたTech総研でのインフラ女子特集に載っている人たちが同僚で、とても楽しかったです。

転職の理由で一番大きいのは、もっと小さなところから新しいものを作り上げる過程に挑戦してみたいということです。次は社員数二桁、設立2年ちょっとの会社で働きます。

狭い業界なので会社が変わってもお付き合いする人は変わらないと思いますし、次も東京で働くので今後ともよろしくお願いします。

2013年4月3日水曜日

SimCity がプレイできるようになるまで

EA/Maxis から新しい SimCity が発売されました。私はこのシリーズのファンなので、昨年の11月に予約し、発売を今か今かと待っていました。2月17日のβテストにも参加しました。発売日にはダウンロードしてプレイし、サーバーに接続できない苦しみも味わいました。

ところが、その後3月8日に異変が起こります。注文がキャンセルされ、6日後の14日にはプレイできない状況になります。その後再びプレイできるようになるまで、いろいろな問い合わせを行い、最後は国際電話をしましたので、その記録です。

2012年11月にゲームを予約注文します。しかし、その後注文に使ったクレジットカードが不正使用され、新しい番号に切り替えてもらっていました。SimCity の注文を切り替えてはいませんでした。

3月7日、SimCity が日本で発売されたのでプレイを始めました！

3月8日、「注文がキャンセルされました」というメールが届いたので、カードに請求がないことを確認の上もう一度購入しようとしました。すると「すでに購入したことがあります」と表示され購入出来ません。EAのサポートにフォームで問い合わせました。この時点ではゲームはプレイできていました。

3月14日に、SimCity をプレイしようとすると「アカウントのシムシティが有効になっていません。 Origin でシムシティを有効にしてください。」というメッセージが現れました。終了するをクリックするとゲームが終了し、全くプレイ出来ません。EA から返答がないので、再びフォームから問い合わせました。

3月15日。全く返事がないので電話しました。意外とあっさりつながったので要件を伝えました。問題を認識したのでエスカレーションすると言われ、電話は終了しました。

3月18日、ためしてみると SimCity が購入できるようになっていたので、もう一度購入しました。すると、購入してマイゲームには現れたのですが、相変わらず「有効になっていません」という表示が出ます。カードの請求も発生しました。状況が変わったのですでに問い合わせていたフォームのチケットにコメントを書き込みました。その一方で、このままでは埒があかないので、Origin の言語設定を英語にすると現れる Live Chat を使って問い合わせました。事情を一から説明すると「処理が遅れてるので、少し待ってほしい。すぐにプレイできるようになるはず」と言われました。

3月19日、相変わらずプレイできないので、もう一度 Live Chat で問い合わせました。問い合わせ番号を伝えたのですが、もう一度最初から説明させられました。すると「ゲームをプレイする権利が何らかの理由で付与されていない。これを解決する専門の部署があるので、電話してほしい」と言われ、アメリカの電話番号を伝えられました。要件を転送して解決できないのかと言いましたが、転送はするが電話も必要だと言われました。日本の窓口に電話したのですが、混雑しているという録音とともに切断されました。

その日の深夜に電話をしたのですが、30分経ってもつながらなかったので諦めました。

3月20日、時間を確保して電話しました。1時間20分待たされてつながりました。問い合わせ番号を伝えましたがまた最初から説明する必要がありました。 20分ほどかかって問題を解決してくれ、その場でゲームを有効にしてくれました。もう一度電話するのは嫌だったので、その場でプレイできるか確認し、電話を切りました。

結局フォームから問い合わせたものは、電話で解決するまでに返事はありませんでした。Live Chat の待ち時間はだいたい50分ぐらいで、こちらは残り時間が出るのでいいのですが、電話で待ち時間が出ないまま延々待たされるのはつらかったです。また、タイムゾーンが東海岸なのでそれに合わせて電話しなければならないのと、秘密の質問を日本語で記入していたためこれを英語で説明するのに戸惑った、というのが日本からアメリカへの電話ならではの苦労でしょうか。

EA のゲームはプレイするまでもゲームというのを身を持って体験しました。結局1週間弱プレイできなかったのですが、その間にそこそこサーバーは安定し、プレイできるようになってました。バグはいっぱい残ってますが... その後は睡眠不足になるぐらいに楽しんでます。

メインは東欧3でプレイしてます。アカウントは Yuryu-Haruka です。ぜひ誰かと一緒にプレイしたいです！

2013年1月4日金曜日

Plextor PX-256M5P vs 東芝 DT01ACA300BOX

初SSD記念でベンチマーク取りました。

両方ともシステム入れて使ってたり、いろんなデータすでに置いている状態なので、理想状態よりは遅くなっているであろうことを申し添えておきます。

SSD: Plextor PX-256M5P

-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 Shizuku Edition x64 (C) 2007-2013 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :   513.421 MB/s
          Sequential Write :   446.646 MB/s
         Random Read 512KB :   381.395 MB/s
        Random Write 512KB :   427.883 MB/s
    Random Read 4KB (QD=1) :    28.854 MB/s [  7044.4 IOPS]
   Random Write 4KB (QD=1) :    50.956 MB/s [ 12440.3 IOPS]
   Random Read 4KB (QD=32) :   388.745 MB/s [ 94908.5 IOPS]
  Random Write 4KB (QD=32) :   348.163 MB/s [ 85000.8 IOPS]

  Test : 1000 MB [C: 24.1% (57.3/238.0 GB)] (x5)
  Date : 2013/01/04 0:36:10
    OS : Windows 8  [6.2 Build 9200] (x64)

HDD: 東芝 DT01ACA300BOX(3TB, 7200rpm)

-----------------------------------------------------------------------
CrystalDiskMark 3.0.2 Shizuku Edition x64 (C) 2007-2013 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :   174.792 MB/s
          Sequential Write :   174.704 MB/s
         Random Read 512KB :    48.242 MB/s
        Random Write 512KB :    71.147 MB/s
    Random Read 4KB (QD=1) :     0.554 MB/s [   135.2 IOPS]
   Random Write 4KB (QD=1) :     0.620 MB/s [   151.4 IOPS]
   Random Read 4KB (QD=32) :     1.516 MB/s [   370.2 IOPS]
  Random Write 4KB (QD=32) :     0.641 MB/s [   156.5 IOPS]

  Test : 1000 MB [D: 25.3% (707.1/2794.4 GB)] (x5)
  Date : 2013/01/04 0:42:54
    OS : Windows 8  [6.2 Build 9200] (x64)

文字通り桁が違います。システムドライブはもう SSD 以外考えられません。

2013年1月3日木曜日

コミケ83報告

コミケ83で Linux Kernel Updates を出します！(31日東X-58b)の事後報告です。

予想外に好評をいただき、50部持っていったのですが11時半ごろに完売してしまいました。「どうせ余るだろうから、ゆっくりいらしてください」と事前にアナウンスしていたので、午後にいらっしゃった方々、申し訳ありませんでした。

いただいたご意見の中に「Linux の変更点を最近追いかけているサイトがないので、まとめてもらえるなら実は需要あるんじゃない」というものがありました。実は KernelNewbies.org がすごくよくまとまっているので、そこを見ながら、自分が気になった新機能についてはまとめていく、なんてことが出来ればいいなぁと思います。

夏コミにも応募します。もし受かれば内容は若干古くなってしまいますが、同じ物を再販して持っていきます。そして、新しい本も出します。今度は調子に乗ってもう少し多めに持っていくつもりです。中身はまだ決定はしていませんが、Linux Virtual Server の中身と、スケジューラーの SMP 対応コードの解説なんかを考えてます。

なお、冬コミ本の中身のうち What's New in Linux 3.7? については、旬を過ぎるとおもしろくないのでBlogに掲載しました。買ってくださった方には少し恐縮ですが、もともとが Web に載っている情報なのでご容赦いただければと思います。

What's New in Linux 3.7?

コミケ83でLinux Kernel Updatesという同人誌を出したのですが、予想外の好評をいただき11時半ごろに完売となってしまいました。

次の夏コミに受かれば再販する予定ですが、Kernel 3.7 のニュースは古くなってしまうので、こちらに掲載します。

What's New in Linux 3.7?

Linux 3.7 に含まれる主な変更点を kernelnewbies.org の記事から翻訳しました。

ARM Multi-platform support

x86 では一つのカーネルイメージが複数の PC 上で動作しますが、ARM は基本的にボードやプラットフォームごとにカスタムのカーネルを作成します。いわゆる組み込み文化です。ところがそのままだと Debian のような distributor が ARM 用の distribution を配布するのが大変なので、複数のプラットフォーム上で動作するカーネルイメージを作成可能にしました。ただし、単に起動するだけといったレベルですので、実用的な使用には現時点ではボードごとの定義が必要です。

ARM 64-bit support

ARMv8 では 64bit コードの実行がサポートされましたので、Linux でも 64bit 版 ARM コードの生成をサポートしました。 x86 と異なり、 64bit ARM は 32bit ARM と全く互換性がないので、別のソースツリーで管理されることになりました。

Btrfs の改善

fsync() の改善: fsync() はデータをディスクにフラッシュするシステムコールです。btrfs はこれまで fsync() が遅かったのでいくつかのアプリケーションでのボトルネックになっていましたが、これが改善されました。 SATA の遅いドライブでも2割～5割、Fusion IO や RAMディスクなどの高速なドライブでは最大7倍程度の性能改善になります。

ディレクトリあたりのハードリンク数上限の解除: Btrfs は従来ディレクトリ内にはハードリンクを20しか許しませんでしたが、今回のバージョンから6万5000個のハードリンクを作成できるようになりました。また、これに伴いディスク上の構造に拡張が加えられました(古いバージョンのカーネルとは互換性がありません)。

Hole punching: ファイルのある一定の領域を未割り当てな状態とする、FALLOC_FL_PUNCH_HOLE オプションをサポートしました。蛇足ですがこのパッチは fusion-io の方からポストされています。やはり SSD にとっては TRIM されているかどうかは重要な様子です。

chattr によるファイルごとの NOCOW 属性のサポート: btrfs ではデフォルトでは COW(copy-on-write) を使用しますが、従来は nodatacow マウントオプションにより COW を無効にすることができました。COW は負荷によっては性能が悪化します。この変更では、ファイル単位で COW を無効にすることができます。ただし、すでに内容があるファイルの属性を変更することはできず、空のファイルにのみ適用できます。すでに中身があるファイルを変更したい場合は、一度テンポラリファイルを作成して属性を変更し、中身をコピーする必要があります。また、COW を無効にすると、チェックサムも無効になります。

perf trace, strace の代替

strace の代替として、新しい "perf trace" が perf profiling infrastructure に追加されました。従来 strace は ptrace() を使っていましたが、perf trace は Linux profiling infrastrcture を使用します。

まだ開発の初期バージョンでシステムコールのみ表示できますが、今後ページフォールト、task のライフタイムイベント、スケジューリングイベントなどをサポートする予定です。また、現在は live で表示することしか出来ませんが、 perf.data のようなファイルを出力して事後の解析ができるようになる予定です。

サーバー側 TCP Fast Open

3.6 ではクライアント側での TCP Fast Open のみサポートされていましたが、3.7 でサーバー側のサポートも追加され、 Linux の TCP Fast Open サポートが完了しました。

実験的な SMBv2 プロトコルサポート

CIFS ネットワークファイルシステムが SMB プロトコル version 2 をサポートしました。 SMB2 はよく使われている CIFS と SMB によるファイル共有の後継で、2006 に Windows Vista により導入されました。 SMBv2 は前のバージョンに比べて高い性能、セキュリティと多くの機能が提供されます。ちなみに Samba 4.0 では SMB 2.1 がサポートされ、また Windows 8 からサポートされる SMB 3.0 のサーバー実装も進んでいます。需要がどれほどあるのか、少し不安なところもありますが、新しいプロトコルのサポートに期待です。

NFS v4.1 の「実験的」が取れました

NFS v4.1 (RFC5661) は長い時間をかけてサポートされてきましたが、今回はじめて「実験的(experimental)」ラベルが取れました。

NFC v4.1 の主な機能は pNFS (parallel NFS) です。pNFS を用いると、ファイルシステムやファイルを複数のサーバーに分散して配置し、並列にアクセスすることが可能になります。

拡張性のある VLAN トンネリングプロトコル

vxlan という、L2 ethernet over UDP のトンネリングプロトコルが Linux に追加されました。 vxlan はしばしば仮想化環境で仮想ネットワークをトンネリングするために使われます。

VXLAN プロトコルそのものは RFC ドラフトで、VLAN の数が 4096 に制限されていることを解決するためのトンネリングプロトコルです。 vxlan では識別子が 24bit に拡張されます。また、使用するUDPポートは一つです。他のほとんどのトンネリングプロトコルとは異なり、VXLAN は 1:1 だけではなく 1:n の接続もサポートしています。VXLAN デバイスは接続先のIPを自動識別してブリッジを自動構成することも可能ですし、または静的に転送設定を記述することもできます。 Open vSwitch のための VXLAN 実装もあります。

Intel SMAP のサポート

Intel SMAP (Supervisor Mode Access Prevention) は、将来の Intel プロセッサに導入されるセキュリティ拡張です。SMAP が有効になると、カーネルがユーザー空間のメモリにアクセスすることが禁止されます。いくつかの exploit の防止に役立ちます。

ext4 の改善

truncate / unlink が高速化されました。あるベンチマークにおいて、60GB のファイルを rm する場合、従来 2.7秒かかっていたものが 0.6秒強まで短縮されています。

ディレクトリエントリのサイズを一定に制限することができるようになりました。

ネットワーク

loopback インタフェースのデフォルト MTU が 64kb に増えました。

まとめると、今回の目玉は ARM アーキテクチャの改善ですが、btrfs や ext4 のパフォーマンス改善など、実際に役に立つ変更も多数含まれています。また、 TCP Fast Open のサーバーサイドサポートも含まれましたので、Web アプリケーションの高速化には 3.7 以降が必須になってくるでしょう。

Part of the above article is translated from http://kernelnewbies.org/Linux_3.7, CC-BY Linux Kernel Newbies

2012年12月29日土曜日

コミケ83で Linux Kernel Updates を出します！(31日東X-58b)

コミケが始まりました！告知が遅くなりましたが、Linux Kernel Updates という Linux Kernel について書いた本を出します。

表紙はきのとなおとさんに描いていただきました！

場所は 31日(月) 東X58b 「低級はっかーズ」です。

目次です。

What's New in Linux 3.7?
TCP Fast Open
Load Average の落とし穴
Completely Fair Scheduler

最近の Linux の変更点と、スケジューラーの解説をまとめました。中身のプレビューです。

みなさまのご来場をお待ちしています。

2012年9月2日日曜日

DNSSEC Look-aside Verification を使うべきでない3つの理由

DNSSEC は本来ルートゾーンから順番に証明していき、最後にホストのレコードを確認するという仕組みになっています。ところが、大人の事情で上位ゾーンに鍵を登録できない人のために、DNSSEC Look-aside Verification (DLV, RFC5074) という仕組みがあります。

DLV は、以下のような仕組みで動きます。

example.net をルートゾーンからの連鎖で証明しようとする
どこかで連鎖が止まっている(上位ゾーンに登録されていない)ため、確認できない
example.net.dlv.isc.org をに DLV レコード(DS レコードとほぼ同等)が登録されていないか確認する
得られた DLV レコードを使って example.net の証明をする

この dlv.isc.org を DLV に使って良いというのは別途設定し、 trust anchor をリゾルバに登録しておきます。

これだけ見ると、一見便利そうなのですが、私は使うべきではないと思います。3つほど理由をあげます。

DLV を有効にすると遅くなる

本来の認証の連鎖が途切れた時に DLV が引かれますので、単純に2倍以上遅くなります。さらに、日本からだと dlv.isc.org の NS が遠くにあるので、かなり待たされます。これは単純にレスポンスの悪化につながります。

グラフは DNSSEC on, DNSSEC on + DLV有効, DNSSEC オフでそれぞれ名前を引いてみた場合の、レスポンスタイムになります(5回平均)。 jprs.jp は DNSSEC の鍵が正しく登録されているドメイン、yuryu.jp はされていないドメインになります。計測は unbound 1.4.18 を用い、毎回の計測の前にリスタートしてキャッシュをクリアしています。また、実際のクエリタイムに近づけるために、 .jp 及び dlv.isc.org の SOA をクエリして、上位ゾーン情報はキャッシュ済みの状態です。

jprs.jp は上位ゾーンからの連鎖で正しく証明ができるので、 DLV のオンオフにかかわらずクエリタイムは一定です。ところが、 yuryu.jp のように証明できないドメインだと、 DLV のクエリが追加で走るのでとても遅くなります。 DNSSEC の on/off よりも重大なパフォーマンスの低下をもたらします。

DNSSEC がきちんと普及すれば問題ないのですが、DLV は「普及過程のためのworkaround」という位置づけです。ほとんどのドメインが署名されていない現状で、このパフォーマンス低下は許容できません。

鍵更新のポリシーが不透明

ルートゾーンの KSK は定期的に更新される、少なくとも5年に1度は更新されることになっています。また、 IANA によって鍵更新ポリシーや記録がきちんとメンテされています。 DLV のキーはこれと同等の基準では運用されていません。一応ポリシーは書かれてあるんですが、そこには「年1回 KSK 更新します」とあります。ところが実際には 2008年から鍵は更新されていません。

ソフトウェアのサポートが不十分

BIND は DLV の trust anchor も含めて自動更新に対応しています。ところが、 unbound の場合はルートゾーンの trust anchor については自動更新に対応しているものの、 DLV trust anchor は自動更新しません。

もし KSK が更新されたとなると、 trust anchor も含めてアップデートしなければなりませんが、これが人力になってしまいます。放置すると証明できないゾーンが生まれることになります。

そして、別の記事にも書きましたが、リゾルバによって挙動が異なる場合があります。利用者も少ないので、枯れているとは言いがたい状況です。

まとめ

以上3つの理由により、少なくとも現状は DLV を使うのは望ましくないと思います。ルートゾーンが署名され、多くの ccTLD も署名されつつありますから、無理に DLV を用いて DNSSEC を導入するのではなく、上位ゾーンの対応を待つべきでしょう。

登録: 投稿 (Atom)