退職ナウ

10月17日付けで、3年半務めさせていただいた某社セールスエンジニアのポジションを resign しました。

この三年半はとても刺激的でした。きっかけは2010年の夏、ポジションのオファーの連絡をいただいた際には、それまでの話とは違い、オファーが目に入った三秒後には「これは面白い、やりたい！」という気持ちが溢れていました。 HR 担当者との Skype 越しでのインタビューでは、「ウチの会社は昼メシ時に一本スキー滑ってる人もいるよ」「うわぁ！オレ絶対入社したいです！」「おいおい、これは面接だからそこは忘れるなよ？」　「で、あなたはこの会社で何をするの？」「私は御社の日本チームを代表するエンジニアになりたいです！」「、オーケー！オーケー！」みたいな、英語が話せないなりにアレな感じではじまりました。

 自身の能力不足で色々なチャレンジがありましたが、恐らく同社のAPACのセールスエンジニアとしては、少なくとも社内のセールスエンジニア組織ではもっとも認知された一人になれたと思います。当初の requirement を満たさないなかで採用としてくださった当初の SE マネージャ、また、採用当初から退職時までワガママを聞いていただいた VP には感謝の言葉しかありません。



いまから一年ほど前、自分が扱っている商材はなんだろうかという、心の中での自問自答に一つの答えが得られました。

時は1990年前半、私が小学生のときまで遡ります。当時、私は父親の仕事用マシンである PC-9801VM2 を”乗っ取り”、そのマシンに乗っていた 2MB のバンクメモリに魅せられていました。

PC-9801VM は 16 ビットのコンピュータで、メモリのアドレスは合計 20 ビットの幅で、最大1MBのメモリ空間しかアドレッシングできない制約がありました。一般的に MS-DOS の 640KB の壁という制限です。当初は「640KB? いったいそんな大量のメモリ、一体何に使うんだよｗ」という会話が普通にありましたが、今となっては 640KB ごときでは本ブログ記事のレンダリングすら不可能なほどの、限られたキャパシティです。

当時のエンジニアもやはりメモリ不足を感じており、 Intel や Lotus などの企業が協力して EMS (Extended Memory System) という規格を作り出し、私が実家で弄っていたバンクメモリボードは EMS 標準化の過渡期にあった製品でした。

そのバンクメモリは衝撃的な経験でした。当時といえば不揮発層はフロッピーディスクがガシャガシャ音を立てて数秒後に漢字変換の候補があらわれ、ハードディスクといえども100ミリ秒単位のアクセス時間があったように思います。そのような中でほとんどI/Oの時間が感じられない「バンクメモリ上のRAMディスク」がやはり快適なしくみで、 2004 年の就職に際しての上京直前にバンクメモリカードを「あ、これは大事なものだから残しておこう」と箱にしまってきたのを今でも憶えています。

私が３年間（、ないしは1990年から）かけて得た答えは、コンピュータのシステムメモリに対して、追加のメモリ空間で容量をブーストをすれば、コンピュータが快適に利用できる、ということです。

MS-DOS 時代は 20ビットのアドレスバス制限のなかで 640KB を超えるメモリ空間の扱いに対して技術的なアプローチが採られました。対して Windows 95 から 32 ビットのオペレーティングシステムになり、現在のプロセッサは 48 ビットのアドレスバスで DRAM をアドレッシングできるため、バンクメモリのような発想は不要だと思われたのですが、しかし取扱データ量の増加に伴い、必ずしも DRAM で全てのデータをカバーできなくなりました。

私が 2011 年から扱っていたデバイスは、 640KB 制限時代のバンクメモリの生まれ変わりでした。フラッシュはストレージとして考えれば高いですが、しかしDRAMやSRAMと比べると恐ろしく安価です（散々”高い”と言われた取り扱い製品は、DIMMと比較すると、定価ベースで５〜６分の１のバイト単価で買えるのです）。この特性を活かして、コンピュータのアーキテクチャでメモリといえばDRAM、二次記憶といえばHDD、が常識になったときに、フラッシュによるメモリ階層の可能性を思い出させてくれたのが、自分が３年間関わったデバイスでした。ヘネパタを読んでも出てこない、今後は DRAM だけではなく容量重視のフラッシュを不揮発層を併用するコンピューティングの時代が訪れる足音を、私は聞いていたのです。

私のなかでは、この結論を得た段階でたぶん満足していたのだと思います。今後、わたしたちはどれだけ抵抗しようが、DRAM, Flash, 磁気メディアを組み合わせてシステムを構成せざるを得ない時代に突入しつつあります。現時点で私は MacBook Air, iPhone, iPad mini を持ち歩いていても全て不揮発層は Flash であり、私を含むユーザ層が Flash を搭載したデバイスでがんがんサーバに負荷をかければ円盤を回している余裕なんてあるわけがありません。 Flash が円盤を置き換えるのはもう完全に時間の問題で、プロセッサ、DRAM、その他I/Oデバイスと二次記憶、という50年来のコンピュータアーキテクチャが変わりはじめる瞬間に立ち会ってきたのだと思います。



なんとなく自分のなかで一つの満足に到ったわけですが、いまの自分は何をしたいんだろう、という問いに対して暫く悩んでいました。まだこの答えははっきりと出ていませんが、その一部は「これは面白い、やりたい！」という４年前の自分の”想い”です。嫁も彼女もナシで、ワンコのラピスも天に召され、守るものが何もない立場の特権かと思いますが :) 自分がやりたい事に時間を費やしてみたいという気持ちに正直になることにしました。

これまで10年間、SIおよびコンピュータ向けのハードウェアベンダ ——つまりはIT業界の仕事に関わらせていただきましたが、今は、自分自身が一番興味があるテクノロジーに自分の時間を費やしたいと思い、ITとはちょっと離れた某スタートアップのお手伝いをすることにしました。まだ自分がどのように貢献できるかわかりませんが、SI時代の経験、ハードウェアベンダ時代の経験を活かして、新しい技術の発展や普及に貢献できれば、と思っています。

この3年半は色々な方にお世話になりました。また、割と時期的に盛り上がっている会社でもあり、会社名や名刺のパワーで IT 業界のさまざまな方とご挨拶ができ、時には吞みながら意見を交わせさせていただき今に到っています。様々な刺激をありがとうございました。

中期的、長期的に自分がどのようなキャリアパスをとるのかはノーアイデア感半端ないのですが、暫くは、IT業界をひとつ離れたところから見つめながら自身がどのように貢献できるのかを模索し、コンピュータの世界を盛り上げられる一人になれる日を向かえられるようにしたいと思います。

p.s.
楽しいお誘いはいつでも大歓迎です。

オープンソースカンファレンス2014 東京・秋で利用したEject-io LTプレゼンテーション

週末に明星大学で開催された OSC2014 初日の懇親会で利用した Eject-io のプレゼンテーションをアップロードしました。

Eject-io (OSC2014 Tokyo/Fall 懇親会LT) from Takeshi Hasegawa

昨年末からのネタで大したアップデートはありませんが、今回はトーマスが走るデモを実装しまして、自作OS界を牽引するあのお方のお子様が魅入ってしまうなど、確実に業界に対してのインパクトは増しております。

Eject-io の詳細についてはこちら（過去のブログ記事）をご確認ください。

次世代I/Oインターフェイス「Eject-io」

なお当日は懇親会を途中で離脱することになったため、前倒しでLT枠をいただきました。ご配慮いただきました @akkiesoft さん、また LT に誘ってくださった @akkiesoft さん、そして Eject でインスパイアしてくれた @akkiesoft ありがとう！

Software Design 2014年11月号に「サーバの目利きになる方法 後編」を寄稿させていただきました。

http://gihyo.jp/magazine/SD/archive/2014/201411

前回はバタバタしておりブログで紹介するタイミングを逃していましたので、今回はタイムリーに。。。。

先月号に続き「サーバの目利きになる方法」として２０ページの記事を掲載していただきました。内容は、これまでのネットワーク技術の変遷（10BASE-5以降）と主要ストレージなストレージ技術（特に今後の普及が確定的なフラッシュストレージ、およびRAID関連の基礎知識）、そしてオマケ程度ではありますがサーバの管理機能について紹介しています。

ネットワーク技術は学生時代（１０年以上前）の知識で書いているところも多いですし、前号同様、知っている方にとっては何も新しい情報はないかもしれませんが、限られたページ数と時間の中で「自分が一緒に働くITインフラエンジニアがいたとしたら、その人に知っておいてほしいこと」を優先的に詰め込みました。

今回も、アプリケーションよりのエンジニアにはあまり知られていない話だと思いますし、興味がないところかもしれません。そんな中でも「へぇ」「なるほどね」と思ってもらえたら、またITインフラエンジニアの方にも何か発見があったり、より専門的な知識の獲得のきっかけになったら有難いです。

今回の記事は、私一人でやらせていただくよりも、ひとつひとつの分野についてより専門的知識を持った方で担当を別けたほうが魅力的な記事になったのでは、という思いもあります。とはいえ、SD編集長さまより全編任せていただいたので、自分の視点から見た世界を、自分のこれまでの体験を振り返りながらまとめました。

各分野のエキスパートによる記事をまとめたければ、そもそも私の所に執筆の話はきていなかったでしょう。また、色々と調べなおして勉強になったので、この機会には感謝しています。今年の冬に向けての軍資金も手に入ります：）


今回の記事はページ数に対してカバーしなければならないエリアがとても広かったので、前編・後編に渡って多くの方にアイデア提供、査読、アドバイス、ご協力をいただきました。ありがとうございました。

執筆期間中にご協力、フィードバックをいただいた方々

石井 宏和さま
板谷 郷司さま
伊藤 宏道さま（日本仮想化技術株式会社）
海老澤 健太郎さま（Riava, Inc）
桑野 章弘さま（株式会社サイバーエージェント）
佐野 裕章さま
須藤 武文さま（さくらインターネット株式会社）
田中 邦裕さま（さくらインターネット株式会社）
東根作 成英さま（レノボ エンタープライズ ソリューションズ株式会社）
宮本 久仁男さま

また、２号とも脱稿が遅れ、技術評論社の Software Design 編集部の方々にはご負担をおかけしました。本当にありがとうございました。

Software Design 2014年10月号に寄稿させていただきました。

すでに発売日から10日近く経過しており機を逸してる感もありますが、技術評論社の Software Design 誌に寄稿させていただきました。

第二特集の「サーバの目利きになる方法」で約２０ページほど解説させていただきました。その他にも読み応えのある記事がいっぱい並んでいますので、まだお求めになられていない方は書店で手にとってみていただけますと幸いです。もちろん今から Amazon.co.jp でも OK です。また、10月18日には続編が掲載されます。

もともとのきっかけは今年4月に開催された qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 ででした。 IT インフラエンジニアとして、今日のIAサーバと向き合うときのポイントを解説してほしいという依頼を同運営からいただき、説明させてもらいました。突貫工事で作ったスライドでしたが、かけた時間に対して、スライドのビュー数も思った以上に伸びました。

qpstudy 2014.04 ハードウェア設計の勘所 from Takeshi Hasegawa

いまはすごいアプリをがんがん作る開発者がいっぱいいるのですが、知り合いと吞んでいて最近話題になるのが、最近のイケイケな動向（ミドルウェアやフレームワークなど）に強いエンジニアでもコンピュータのことはあまり知らないエンジニアが増えているという話をよく聞きます。それは、 qpstudy 2014.4 でプレゼンをしたときのその場のフィードバックや関連するタイムラインなどにも感じました。

2010年頃、自分がシステム構築ビジネスのプリセールスSEとして活動していたとき、システム構築ビジネスでサーバの構成や見積もり、導入といった話をうまくまとめたバイブル的な書籍がないか？と思い探してみたことがあります。今ではあれば LINE 株式会社の佐野さまが当初イメージしたものにいちばん近い書籍を出されており、今回の執筆にあたってはページ数制約のなかでもう一歩技術側に踏み込んだ内容にバランスできればいいなと思って取り組みました。




インフラエンジニアの教科書
佐野 裕
固定リンク: http://www.amazon.co.jp/dp/4863541333

残念ながら、私がバイブルを探した”その時”には、自分が欲しいと思った本は見当たりませんでした。今回は機会をいただいて、そのときに自分が読みたかった書籍の１０％ぐらいの内容をまとめられたかな？と思います。

というわけで、私も別にそれほどハードウェアや機器選定で何かすごい経験があるわけでもないですし、諸事情により調査に時間をかけたり集中して原稿に取り組むことができなかったので、自分自身として内容に満足していないのですが、かけた時間相応でまとめられたかなと思っています。正直特集名が「サーバの目利きになる方法」になっているゲラを見た、目利きになんてなれていない私は、動揺を隠せませんでしたし、今でもドキドキします。

各エリアの専門家からしたらオママゴトのような内容になっていますし、私の Twitter タイムラインにいる方や Software Design 誌を長く読まれている方がったら当たり前のことも多いと思いますが、そうではない、若手のエンジニアの方やアプリケーションサイドのエンジニアの方に、サーバや構成パーツについて参考になったり興味がわいたり、ということがあれば嬉しいです。

今回の記事やスライドに着手するきっかけを下さった qpstudy の皆さん、また今回、２号に渡り約４０ページものページを託してくださった Software Design 編集部の皆さんには大変感謝しています。

特に SD 編集部の皆さんには、、、、二ヶ月にわたり締め切りを守れずに申し訳ありませんでした。私が技術評論社ではじめての原稿をやらせていただいた機会は、他の方の原稿が落ちたときの代打でした。これまで数回にわたって代打を務めさせていただき得た信頼を、ここ１年でいくらか失ったのではないか、と反省しています。次号の入稿が終わったらモツ鍋を食べにいきましょう。きっと乾杯の前にお詫びすると思います。 (T_T)

Nexys 4 と ISE Design Suite で何か作ってみる（後編）

前編では、新しいプロジェクトを作って、プログラム可能なファイルを生成するところまでを見てみました。続いて実際に FPGA にプログラムしてみます。

■ Micro USB コネクタによる JTAG 接続

Nexys 4 を Micro USB ケーブルで開発機に接続します。このためには、あらかじめ Nexys 4 上のジャンパを設定しておきます。設定方法は Nexys 4 のリファレンスマニュアルに書いてありますが、参考までに引用しておきます。

 

JTAG を利用するには JP1 の真ん中の２本のピンをショートさせておきます。ジャンパの設定を終えたら Micro USB ケーブルで開発機に接続し、 Nexys 4 の電源スイッチをオンにします。

今回は VMware を使っているため、仮想マシンに USB ターゲットを接続します。

また、初回接続時は USB Serial のドライバがロードされるまでにしばらく時間がかかりました。 うまく接続できていれば、デバイスマネージャで COM ポートが確認できるはずです。

■ いざプログラム

Project Navigator に戻ります。先ほど実行した Generate Programming File の下にある、 Configure Target Device のツリーをひらき、 Generate Target PROM/ACE File をダブルクリックします。

下記の警告が表示されますが無視します。

ISE iMPACT というプログラムが立ち上がってくるので、ここで iMPACT Flows から Boundary Scan を選択し、左側ペイン内を右クリックしてショートカットメニューから Add Xilinx Device をクリックします。

 

FPGAのプログラムに使用したい .bit ファイル、つまり先ほど生成したロジックを含むファイルを選びます。ここでは test.bit ファイルがありますのでこれを選択します。

iMPACT の右側ペインに表示された Xilinx のチップアイコンを右クリックして、ショートカットメニューから Program を選択します。

上記操作で、 FPGA へのプログラムが開始され、プログラムが完了すると Program Succeeded という表示がなされます。

■ 動作テスト

FPGA へのプログラムが完了すると、 DONE LED（FPGA右上）が点灯し、組んだロジックが動作しはじめます。 SW0 と SW1 を操作すると、対応する LED が点灯／消灯するのが確認できます。

なお、今回は FPGA に通電後、 JTAG ケーブルを通じて直接プログラムしました。ボードの電源を落とすとプログラム内容は消えてしまいますので、改めてアップロードする必要があります（もしくはコンフィグレーション ROM に bit ファイルの内容を書き込んで、電源オン時に自動ロードされるようにします）。

Nexys 4 と ISE Design Suite で何か作ってみる（前編）

FPGA いじりをはじめるにあたって色々調べたのですが、とりあえず簡単なロジックを FPGA にプログラムするまでの手順、とくに今回買った Nexys 4 向けの具体的なものが見当たらなかったので、ここにメモがてら残しておくことにします。

今回は作業環境とライセンスの都合上 ISE Design Suite を使い、真っ白なプロジェクトから実際に Nexys 4 向けの bin ファイルを生成し、プログラムしてみます。

これ見れば誰でも FPGA いじり始められますね！みんなあそぼうず。



■ 新しいプロジェクトを作成する

まず ISE Project Navigator を起動し、 New Project... をクリックします。

次にプロジェクト名を指定します。今回は myproj1 としました。またプロジェクトの配置先フォルダを指定しました。プロジェクトの配置先フォルダに myproj1 というサブフォルダが作成され、その中にプロジェクト一式が保存されるようです。

次の画面ではターゲットの FPGA のモデルを指定します。 Nexys 4 の場合はリファレンスマニュアル(PDF)およびサイトの表記から XC7A100T-1G324C というチップだとわかりますので、これにあわせて選択します。なおスピードは -1 が遅い、 -3 が速いモデルで、 324C というのは 324 ピンの BGA パッケージであることを示しています。

■ 制約ファイルを追加する

プロジェクトが作成できたら、次に、プロジェクトに制約ファイルを追加します。 myproj1 を右クリックして Add Copy of Source... を選択します。右側に + マークが付いたアイコンがありますので、これを押してもよさそう。

Nexys 4 のサイトから入手した UCF ファイルを指定します。

■ 新しい VHDL ファイルを作成する

次に、プロジェクトに新しい VHDL ソースファイルを追加します。 New Source... をクリックします。

ファイルの種類として VHDLを選択しました。また VHDL ファイル名はとりあえず test.vhdl としてみます。

Define Module というダイアログが表示されますが、とりあえずここはそのまま。

ウイザードを終了すると、下記のようなからっぽのテンプレができています。

■ ロジックを書いてみる

早速何かかいてみます。 SW0 がオンだったら LED0 を点灯させ、 SW1 は逆にオフのときに LED1 を点灯させます。

■ 制約ファイルを編集する

ここで SW とか LED というポート（各２ビット）を使っていますが、このポートが FPGA のどのピンに対応しているかを示すため制約ファイルを編集します。 Nexys4_Master.ucf ファイルで以下の行を有効化します。

NET "sw<0>"            LOC = "U9"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L21P_T3_DQS_34,                    Sch name = SW0
NET "sw<1>"            LOC = "U8"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_25_34,                            Sch name = SW1

## LEDs
NET "led<0>"            LOC = "T8"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L24N_T3_34,                        Sch name = LED0
NET "led<1>"            LOC = "V9"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L21N_T3_DQS_34,                    Sch name = LED1


■ 論理合成、 bit ファイルの生成

ここまでできたら下記スクリーンショット中の ▶ ボタンをクリックしてプロジェクトを Implement してみます。画面下部にログが表示されます。

 
Implement が終わったら、次は Generate を行います。 test - Behavioral (test.vhdl) を選択した状態で、下の Process: から Generate Programming Fileを選択します。

最終的に Process "Generate Programming File" completed successfully と表示され、先の Generate Programming File の左側に緑色のチェック印が出れば OK なようです。これでとりあえず FPGA にアップロードできそうなファイルができました。

■ 後半編へ

後編では、今回生成した bit ファイルをアップロードしてみます。

Nexys 4 サイトから入手できるファイル

今回買ってみた FPGA トレーニングキット Nexys 4 の使い方は、販売元の Digilent 社のサイトにいろんな情報や、デザインに使うためのファイルがあります。

■ サイトを覗いてみる

Nexys™4 Artix-7 FPGA Board

ページ上部は製品の仕様などが書かれていますが、このページのいちばん下を見ると、実際にいじくるために参考となる、必要となるファイルが置かれています。


■ サイトから入手できるファイル（特に大事なもの）

Nexys 4 reference manual
製品マニュアルです。先のブログ記事に購入したパッケージの写真をのせましたが、製品にはマニュアルが含まれていないので、このファイルをダウンロードして参照することになります。 FPGA への電源供給方法やプログラミング方法のほか、各種 I/O がどのような仕様になっているか等も解説されているので、このファイルを一通り見ると、このボードでどういう I/O ができるかは一通り判るようになっています。

Nexys 4 schematics
トレーニングボードの配線図。

Nexys4 Master UCF File for ISE designs
Nexys4 Master XDC File for Vivado designs
これらのファイルは制約ファイルと呼ばれるものだそうです。 Nexys 4 は ALTRIX-7 を載せたトレーニングボードですが、 FPGA から出ているピンからは各種 I/O に接続されています。制約ファイルには、この FPGA ピンと基板上の I/O の対応が記述されています。


■ 制約ファイルを見てみる
 
各ピンからどの I/O に接続されているかは先のリファレンスマニュアルや配線図をみるとわかるのですが、デザイン環境で作ったロジックを実際の I/O ピンに割り当てるための定義サンプルがこのファイルに含まれています。UCF ファイルは今回利用する ISE DS
 用、XDC ファイルは新しいデザイン環境である Vivado DS 用のファイルです。 UCF ファイルの中を覗いてみると

## Clock signal
#NET "clk"   LOC = "E3"    | IOSTANDARD = "LVCMOS33";                    #Bank = 35, Pin name = IO_L12P_T1_MRCC_35,                    Sch name = CLK100MHZ
#NET "clk" TNM_NET = sys_clk_pin;
#TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 100 MHz HIGH 50%;

## Switches
#NET "sw<0>"            LOC = "U9"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L21P_T3_DQS_34,                    Sch name = SW0
#NET "sw<1>"            LOC = "U8"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_25_34,                            Sch name = SW1
#NET "sw<2>"            LOC = "R7"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L23P_T3_34,                        Sch name = SW2
#NET "sw<3>"            LOC = "R6"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L19P_T3_34,                        Sch name = SW3
#NET "sw<4>"            LOC = "R5"    | IOSTANDARD = "LVCMOS33";        #Bank = 34, Pin name = IO_L19N_T3_VREF_34,                    Sch name = SW4

こんな感じの定義が並んでいて、上記の部分では水晶が E3 というピンに、スイッチは U9, U8, R7, R6, R5... というピンに繋がっていることがわかります。ここで先の Reference Manual を見てみましょう。こちらでもやはり、 E3 が 100MHz の水晶発振子に接続されていることが確認できます。

この制約ファイルは全てコメントアウト状態になっていますが、たとえば CLK の部分をコメントアウトするとVHDL などから CLK というピンが見えるようになり、 sw<0> 〜 sw<3> のコメントアウトを解除してあげた制約ファイルをプロジェクトファイルに追加すると、 から sw(0)〜sw(3)  という形で各ポートにアクセスできるようになります。

仮想マシン上で Vivado Design Suite が使えない

先日 FPGAトレーニングキットを買ったわけですが、さっそくひとつ目の罠にはまりました。仮想マシン上で Vivado Design Suite が使えないんです。。。これから Xilinx FPGA に手を出す方はお気をつけください。

Xilinx の開発環境はいま下記のふたつがあります。

• Vivado Design Suite
• ISE Design Suite

このうち ISE Design Suite は過去のバージョンのもので、2013年に機能追加を終えてメンテナンスフェーズに入っています。現在は Vivado Design Suite がメインストリームということのようです。

それで、新しい Vivado Design Suite をインストールしてみたのですが、動かしてみたら、まさかのライセンスがアクティベートできない罠にはまりました。

Vivado 2013.3 can't find license

Vivado DS, ISE DS ともに無償でダウンロード可能で、論理合成などの機能を無償で利用するためには Xilinx のサイトで登録の上 WebPack ライセンスを取得します。 ISE DS の無償ライセンスはフローティングライセンスが取得できるのですが、 Vivado DS の無償ライセンスはノードロックになっていて、しかもどうやら VMware の MACアドレスを検出して弾いているっぽいですね。。。。

私は MacBook Air 上で VMware Fusion を動かして Windows や Linux を動かしているので、上記の制限にひっかっかります。この制限は次期バージョンの 2014.03 で取り除かれる予定、とあります。

ちょっと触ってみた感じ新しい Vivado のほうがインターフェイスが良いし、複数のツールがひとつの開発環境に統合されているようで具合よいのですが、今回買った Nexys 4 は ISE DS でも対応できます。

先のディスカッションを見ると Xilinx の窓口に問い合わせをすると Vivado DS のフローティングライセンスを出して対応してくれたりするようですが、今回はとりあえず ISE DS にダウングレードして、通常フローで取得できるフローティングライセンスを使うことにしました。

FPGAトレーニングキットを購入

突然ですが FPGA トレーニングキットを買ってみました。

大学生時代は「ミドルウェアより下のレイヤには絶対手を出さないぞ」と思っていたのに、気付けば OS やら VMM のレイヤに取り憑かれ、就職して暫くまでは「ソフトウェアより下のレイヤには絶対に手を出さないぞ」と思っていたのに、気付けばドライバやらマイコンをいじりはじめ、と興味の対象が順番に低レイヤにおち続けている hasegaw です。今回はどうして FPGA 買っちゃったのかについてでもポロっと書いておこうかなと。

■ きっかけはまさかの Minecraft


ある日偶然ネット上でみかけたのが Minecraft 上でぷよぷよを実装しちゃったという動画でした。 Minecraft って全部正方形で構成されてる雑ゲーだと思ってたんですが、ここで Minecraft に対する認識を改め、 20 ドルほど出して Win/Mac の製品版ライセンスやら iOS 版のアプリやらを買い始めます。

解説動画もあったので見てみると、レッドストーン回路なるものがゲーム上に存在して、そこで論理回路が自在に組める仕組みになっているそうで（さすがに先の動画は素の Minecraft では厳しいようですが）。もちろん複雑なものを作るのは大変みたいですが、下手な”高レベルなブロック”を組み込むよりも、ゲーム上で論理回路を組めるようしておこうって発想はおもしろいですね。

■ 回路シミュレータで遊びはじめる

Minecraft で遊んでいたりもしたのですが、 iPad で使える数百円の回路シミュレータで遊んでいるうちにもっと大きな回路が書きたくなってきたりして、最初はブレッドボード上にでも組もうかと思ったのですが、回路が複雑になってくると配線引き回すのも大変なので結局 FPGA に移ることにしました。

■ FPGA トレーニングキットを購入

ハードウェアもロジックもまったくの素人ですが、今回買ってみたのは Digilent 社の Nexys 4 です。 ALTERA ベースだと DE0 などのボードが1万円前後で手にはいる？ようですが個人的には Xilinx ベースが良かったので、適当なボードを探していたら Digilent 社の Nexys 2/3 が入門向けとして良さそうでした。 Nexys 3 だと Spartan-6 が載っているということですが、これだと一世代古いチップになります。今は Nexys 4 という、 ARTIX-7 搭載モデルが出ていたのでコレにすることにしました。

まだド素人がボードを買っただけの状態ですけど、 Nexys 4 は前世代と比べると 7 セグやスイッチの数が倍増しています。また、購入前にいろいろ調べていると、 Nexys 3 だと 1080p のビデオ信号を出そうとすると性能が足りないっぽいので、どうせなら新しいモデルを買っておくことにしました。 Nexys 4 は Nexys 3 と比べて 4000〜5000 円ほどUPですが、 I/O が増えて FPGA クロックも高くなっていれば十分にその価値はあるんじゃないかと思います。

ついでに Nexys 4 だと別売の JTAG ケーブルを買ったり工作したりせずとも、 JTAG として使える Micro USB ポートがあります。つまりは手許の PC におもむろに USB 接続すると JTAG 接続状態になるわけです。 4000~5000 円の追加投資でここまで性能アップ＆お手軽になるのなら全然アリですね。

Nexys 4 ピンポイントの情報源があまりなくて不安ですが、 Digilent のサイトからダウンロードできるマニュアルは丁寧（？）に書かれているので、ピンポイントな解説や書籍がなくてもいじれそうで安心しています。一点ひっかかるとしたら ARTIX-7 になると BGA パッケージしかないので、今後何か基板を製作しようと思ってもたぶん自分でパーツ実装できないという問題はありそうです。 FPGA パッケージひとつで1万円ぐらいするみたいだし。まあ、何か基板を製作するような事になったら、そのときは Spartan ベースでやるなりすればいいでしょう。

国内でも取り扱いがある代理店はいくつかあるようですが、結局 Digi-Key から買いました（本体価格　約３１０００円＋諸経費にて合計３８０００円弱）。日本時間で金曜日の日中に注文したら、その夜にはミネソタから発送され、月曜日の日中にはヤマトが自宅まで配送してきてくれました。アメリカから通販したのって今回が初めてですが、72時間ぐらいで届いちゃうってすごいですね。

いままで経験がない分野なのでワクワクしてますが、果たしてどこまで遊べるか。。。。何かできたらまた書きたいと思います。

PostgreSQLのXLOG_BLCKSZをいじってみる(追記あり)

PostgreSQL のコンパイル時に指定できるオプションとして XLOG_BLCKSZ （トランザクションログのブロックサイズ）があります。

XLOG_BLCKSZ のデフォルト値は 8KB (BLCKSZと同じ) なのですが、 PostgreSQL のトランザクションログのフラッシュコードを覗いてみると、この値はトランザクションログ書き出し時の最小単位として利用されます。

これは、たとえばトランザクションログに100バイト分のデータをコミットしたいときでも XLOG_BLCKSZ が 8KB がであれば 8KB 分の write() が発生しフラッシュされ、もし運悪くログが境界をまたいでしまうようなケースでは XLOG_BLCKSZ の n 倍の書き込み、つまり 16KB などの書き込みが発生することになります。

また、コードを見る感じだと PostgreSQL のトランザクションログ書き込みは、同じページを繰り返しフラッシュします。たとえば、とあるページに 100バイト、100バイト、100バイトのトランザクションを毎回フラッシュするということは、同じページ(ファイル内のオフセット)に対して3回 write() されフラッシュする実装になっているようです。

フラッシュベースのストレージを使っていると書き込み量はデバイスの利用期間に影響しますので、8KBは（シークコストが大きかったディスクの時代ならともかく）少なくとも、現時点のフラッシュの時代にはちょっと大きすぎるかなあと思って XLOG_BLCKSZ を小さくコンパイルしなおしてみました。

XLOG_BLCKSZ は src/include/pg_config.h に定義されていますので、その値を2のn乗（ただし1024以上）に設定します。今回はデフォルトの8192, 今頃のフラッシュデバイスでよくありがちな4096、そして512は指定できないけども1024にして試してみました。

なお評価は以下のようなスクリプトを作成して実行し、 diskstats からブロックデバイスへの書き込み量をモニタします。ついでにフラッシュへの物理書き込み量も同時にとっていますが、ここでは評価しません。

結果はこんなかんじでした（この書き込み量はトランザクションログだけでなく、表領域などを含む、 PostgreSQL の書き込みの合計値です）。

グラフを見ていただくと判るとおり XLOG_BLCKSZ を 8192 から 4096 に変更するとストレージへの書き込み量が24%ほど削減できました。この効果は実際のアプリケーションでどれぐらいの大きさのログが定常的に書き込まれるかによって変わると思いますが、一定の効果はありそうです。

XLOG_BLCKSZ = 1024 ではさらに書き込み量の減少は確認できましたが、しかし4096の場合からの差を見る限り、1024まで下げてもそれほどのインパクトはなさそうです。最近のファイルシステムの書き込み単位は1ページ4KBぐらいでしょうし、そもそも4KBを切るような書き込みは苦手なフラッシュストレージも多いので、とりあえず4096が落としどころな値ではないでしょうか。

さて、気軽に XLOG_BLCKSZ を変えてみたのですが、トランザクションログのフォーマットが変化するためデフォルトの設定のデータベースファイルが使えなくなります（トランザクションログだけ？それとも全体を？）データベースファイル群を initdb で初期化する必要があります。またトランザクションログを利用するレプリケーションなどの互換性にも影響があるのかもしれません。

追記

上記の内容はブロックサイズ 4096B でフォーマットされた（最小単位が 4K バウンダリな） ioMemory PX600 を利用して行っていました。 XLOG_BLCKSZ = 1024 を試すならフォーマットを 512B に変更すべきでした。すみません。ということで改めて XLOG_BLCKSZ = 1024 の値を調べてみたところ、 4096B フォーマット上の結果と比べると大幅に書き込み量が減りました。

 
先の結果との差は、ファイルを書き込むときに、 XFS がパディングしたものと考えられます。

 結果として、 XLOG_BLCKSZ = 8192 （デフォルト）の状態、すなわちトランザクションログのブロックサイズ 8192B で特定のワークロードを流した場合と比べ、 XLOG_BLCKSZ = 1024 （最小値）でワークロードを流した場合では、書き込み量が約半分になることがわかりました。

先にも書きましたが 4096B 未満の I/O はフラッシュストレージの特性上性能が出しづらいケースも考えられる（仮に512BアクセスできたとしてもCopy-Modify-Writeを行っている）ほか、ホスト側からの書き込み量に対してデバイス内でより大きな Physical Write が発生しているケースもあるので Host write の値にとらわれるのは危険です。 ioMemory シリーズのような 512B 単位の I/O もネイティブに扱えるデバイスなら 1KB などのアグレッシブなトランザクションログ ブロックサイズを利用し、フラッシュの寿命を約２倍に伸ばせそうです。

サーバーさんに本気を出してもらうために憶えておきたい設定項目

cpuspeed がオンだと....
— はせがワン (@hasegaw) 2014, 5月 29

ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。

経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。

パワーマネジメントに関する設定はオフにする

UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。

Hyper Threading はレイテンシーとスループットのトレードオフ

Hyper Threadingは、たぶん、コア内でパイプラインを取り合うからなのだと思いますが、レイテンシーの悪化原因になったりします。隣の誰かよりもはやく売り買い注文を出したりしたいような場合にはあえてオフにすることも多いようですが、ただRDBMS等ですと慢性的にプロセッサの処理能力が足りなくなるので、ある程度の犠牲は仕方無いと割り切って有効にしておくのがよいでしょう。

VT-dはレイテンシーを増すので不要な環境ではオフにする

仮想化環境でPCIパススルーなどと呼ばれる機能を提供するための機能がVT-dです。この機能はさりげなくI/Oレイテンシーを増したりするので使う予定が無ければオフにしておきましょう。


上記も具体的にするとCステートオフとか色々あるわけですが、後述のドキュメントを見るとだいたい網羅されているので適当に済ませることにします。他にも色々あるでしょうが、割と勢いで書いているので何かあれば教えてください。

あとは番外編です。

ファン設定を全開に

コンピューターによってはファンの設定ができますが、こちらも最強にしておきます。うっかり熱くなると動作クロックが落ちたりします。また最近のサーバーはできるだけファンを回さないように作られていますので、コンピューター内に発熱しやすいコンポーネント（GPGPUなど）がある場合、十分な風量を確保できずに熱が滞留するケースがあります。自宅やオフィスに置いてあるサーバでなければファン設定は全開にしておきましょう。

OOB BMCのファームウェアをアップグレード

本体のファームウェアは製品発表当時とかだと色々抱えていたりしますし新しいものに上げてつかうのが一般的だと思いますが、時々ひっかかるのがOOB BMCの問題です。サーバーなどについているマネジメントプロセッサのファームウェアによってはシステムの性能に悪影響を与えるケースがあります。できるだけ最新に保ちましょう。

マルチプロセッサ構成ではPCI Expressバスのスロットに気を付ける

NUMAアーキテクチャのコンピュータではPCI Expressバスの利用時に接続先スロットに注意します。Nehalem以降のサーバでPCIeに何か挿すということは、どいつか特定のプロセッサの端にPCIeデバイスを繋ぐということです。大抵の場合は第１プロセッサに接続するほうがいいようです。OSによりますがデフォルトでは特に、最初のCPUコアで割り込みなどを捌こうとする傾向がありますので、第１プロセッサに繋いでおいたほうが比較的無難です。特に二番目以降のプロセッサにPCIeデバイスを繋いだ場合には、デバイスがいる側でドライバが動いているか等確認しましょう（アフィニティ）。UEFI/BIOSの設定からはかけ離れてきたので割愛します。

サーバーベンダーが提供する低レイテンシー向けガイドも見ておこう

サーバ—ベンダーによっては低レイテンシー利用向けのガイドを出していたりします。低レイテンシー＝大体の場合はコンピューターの節電機能などを極力オフにして性能を稼ぐための設定指針ですので、いいとこ取りして活用しましょう。

Configuring Low-Latency Environments on Dell Power Edge Servers (PDF)
Configuring and Tuning HP ProLiant Servers for Low-Latency Applications White Papaper (PDF)

これ読んで精進しよう.... RT @la_luna_azul: ブログってた。リモートからBIOSの設定を変更して再起動して対応完了:(；ﾞﾟ'ωﾟ'): / ioDriveとかフラッシュを使うときはBIOSの設定に気をつける https://t.co/dYQ3LQnt2Q
— はせがワン (@hasegaw) 2014, 5月 29

@hasegaw パワーマネジメントを入れないと、ターボブーストが効かなくなるというトレードオフがあります。シリアルな処理でスループット稼ぎたかったらそのあたりも考慮しますね。

— M (@PrairiePrairie) 2014, 5月 29

ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々

先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると：

1. ファイルシステム上に書き込み可能な状態でファイルをオープンする。
2. 一定ペースで、ファイルへ Buffered I/O で書き込み。
3. ファイルをクローズする。

このとき、特定条件下のXFSでは、（２）の段階では全然フラッシュが発生せず、（３）の段階でまとまったフラッシュが発生するのだそうです。

ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション（ミドルウェア）からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linuxでは5秒ごとにメモリ上のダーティーなページがファイルシステム上に反映されるというのですが、今回はそのような動作になっていないようです。

またお話を聞いていると、

• Ext3 でフォーマットされた、ハードディスク上の / では現象が発生しない
• XFSでフォーマットされた、 ioDrive 上の /data (仮) では現象が発生する
• ioDrive + VSL2, ioDrive2 + VSL3 のどちらでも発生する
  ※ VSL = Virtual Storage Layer; ioMemoryシリーズ用のドライバソフトウェア

とのことです。

Linuxカーネルの配布元、リリース、利用するファイルシステム、利用する ioDrive シリーズとドライバやファームウェアのバージョンなどによって食いあわせ的な問題も経験したことがあります。

ただ、今回の場合、ここまでの情報より、そもそもブロックデバイスへのI/Oがきていない（であろう）こと、 VSL2 と VSL3 で問題が再現するということから、個人的には、カーネル側（Linuxのブロックレイヤやファイルシステムドライバ）の挙動なのではないか、と切り分けました。

以下が、今回相談いただいた問題の再現例です（検証は ESXi 上の CentOS 5 で行っており、また ioDrive は利用していません）。



ioDrive を使っているユーザーさんは、こういう細かな問題も乗り越えながら日々運用していらっしゃるんだなあ、と思うと、頭が下がる想いです。


ところで、私は ioDrive をはじめとする ioMemory のベンダーである Fusion-io に務めていますが、いまのポジションでは、このような"カーネル依存"やOSのデザイン上のご相談なども度々いただきます。OS/ミドルウェアなどの動作上の問題：ioMemory の動作上の問題の割合＝４：１、もしくはもっと前者の割合が多いように感じています。

Fusion-io のエンジニアをやっていると、ioMemory をいじっているよりも、関連するソフトウェアを弄っていることのほうが多かったりします。もともと ioMemory を使うユーザーは「ioMemoryの性能を限界まで使いたい」とはちっとも思っていなくて、「 ioMemory を使ってシステムを快適にしたい」「運用を改善したい」という動機であることが多いはずです。

幸いにも、この会社が持っている ioMemory シリーズは、半導体ストレージとしては業界トップクラスの性能ですから、デバイスの性能自体にあまりナーバスになる必要性はありません。お恥ずかしながら、実際、私は ioMemory のIOPSスペックをひとつひとつ憶えていませんし、する必要もありません。 ioMemory のスペック値を憶えても CPU やメモリのパフォーマンス、システムボードの設計で実際に利用できる範囲は下ブレも上ブレ（！）もしますし、トラブルシュートでデバイス側に執着しても解決するものは少なく、システム上でソフトウェアがどう動いているかに注目しなければ、大抵の問題は解決しないと思います。

 私自身がプラスアルファの活動に費やせる時間には限りがありますし、自分の”守備範囲”はお世辞にもそれほど広くないので、限界があります。ですが、自分ができる範囲で、 ioMemory ユーザーにはデバイスだけでなく、関連する”ソフトウェア側の落とし穴”もうまく乗り越えて、確信をもって使ってもらえるようなれば、と思っています。

Fusion-io ioDriveの状態をohaiで取得する

ohai プラグインを書きました。

ioMemory VSL3.x 専用です。 ioDrive 第一世代向けの旧リリースである VSL2.x では使えません。

ココログからBlogger に移転。

これまでココログを利用していましたが、思い切って blogger に移転させました。

理由ですが、ココログのケータイ向けブログページが検索対象として検索エンジンに引っかかっていたためです。

昔は自分で Web サーバを立ててCMSというかtDiaryなども時前管理していたのですが、就職してからはspam対策やらセキュリティホール対策などを行うのがけっこうな苦痛になっていました。当時ページランク５、何もしなくても数千PVいただいていたアドレスを消してしまったんですね。

2007年にブログで改めて始めようと思ったときに、スパム対策などを丸投げしたい、でも以前のように自分でデザインなどは済ませたいと思って有料サービスを使い始めました。しかしある日テンプレートの仕様がかわったようでカスタマイズしたデザインを使っているとブログが更新されないという問題にブチあたり、標準テンプレートに切り替えます。この段階でココログのプランもひとつ下がりました。いやはら、ラクをしようと思っても思い通りにはいかないモンですね。

しかし、追加料金プランで独自ドメインを使っているのに、意図しないアドレスで自分のデータが拾える状態になりました（当初はこんなこと無かったと思います）。

これには色々と思うことがありました。最近気になっていたこととして、はてなブックマーク等でブックマークされた際にココログのケータイ向けページが登録されてしまい、意図通りのリンク先（見栄え）にならない問題がありました。

Next って何？みたいな。ココログの設定画面などをチェックしたのですが、何度か調べたものの根本的解決方法もなく、サービス側でされることもなかったので、移行を考えていました。で、データの移行方法、各種利便性や欲しい機能、運用の手間などについて色々思案していたのですが、最終的に Bloggerに落ち着いた、というわけです。

手順としては

• ココログの.TXTエクスポート機能で過去のエントリをエクスポート
• http://movabletype2blogger.appspot.com/ で.TXTファイルを Blogger 形式(.XML)に変換
•  Blogger に過去エントリをインポート
  この際「インポートした記事を公開しない」ようにしておくとパーマリンク設定が可能に
•  各記事のパーマリンク見直し
• ココログ当時のURL一覧、Blogger移動後のURL一覧を wget, シェルスクリプト等で作成し Excel 上で付き合わせ
• Blogger のリダイレクト機能で過去の記事URLから新URLへジャンプするよう設定
• 記事中にある写真データ（ココログに向いている）を削除し、再度張り直し

けっこうな作業量でしたので合計で５〜６時間ぐらいはかかりました。 記事が正味１５０本程度しかなく、画像もほとんどなかったのが救いですね。