GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Michael Prokop , 翻訳者 吉田 英人 投稿日 2010年4月1日
もしあなたが Western Digital 製のディスクを使っていて,そのモデル名に "EARS" という文字が含まれていたなら,そのパフォーマンスの低さにすでに悩まされているかも知れない。問題の原因として最も可能性が高いのは,Western Degital がコンシューマ向けディスクに新たに採用した Advanced Format Technology (PDF) である。通常のディスクがユーザデータを 512 バイトの物理セクタサイズ で記録しているのに対して,Western Digital の Advanced Format Technology は 4096 バイト (4Kバイト) 単位のデータセクタを使用する。ディスク上のデータ配置形式(アライメント)は,ハードウェアの性能を最大に引き出すために重要なものだ。不適切なデータアライメント設定は必要な read/write 回数を増やし,結果的にパフォーマンス低下を引き起こす。他のベンダが同様な 非 512 バイトセクタのディスクを出荷するのは時間の問題なので,この問題には遅かれ早かれ気付くことになるだろう。
以下は Linux カーネルプログラマ Teodore Ts'o 氏 のブログからの引用である。
この問題が当初考えていたよりも難しいものであることは明らかです - Linux のストレージスタックは,その大部分がパーティションのアライメントや論理ボリュームを考慮した構造にはなっていないのです。[...] この種のアライメントはハードウェア RAID あるいはソフトウェア RAID を使用する場合,とりわけ RAID 5 において重要です。ストライプ境界に合わせて書き込みが行われれば,read-modify-write というオーバーヘッドの回避が可能だからです。
ハードウェアレイヤ(コントローラなど)だけでなく ソフトウェア (ドライバ,パーティショニングソフトウェア,...)においても,512 バイトのセクタサイズが想定されていることが考えられる。その問題回避と後方互換性実現のために Western Digital のドライブでは,実際の物理セクタサイズを偽る方法が採用されている。つまり物理的な 4K バイトセクタ値を上位レイヤに対して返す代わりに,ファームウェアが 512 バイトセクタを内部的にエミュレートするのだ。しかしこの方法は,上位レイヤのデータアライメントが 4K バイトセクタに適さない場合には,先程説明したパフォーマンスの問題を即座に発生させる。512 バイトの論理セクタと 4K バイトの物理セクタを持ったディスクに対して,そのアライメントに合わない方法で部分的な書き込みが行われるため,結果的に read-modify-write のオーバーヘッドが発生するからだ。
Vista 以降の Windows は,先頭パーティションを 2048 セクタから開始しているので 4K バイトディスクへのアライメントには適している。しかしそれ以前の Windows や 有名な Linux パーティショニングソフトウェアの旧バージョンでは,先頭パーティションを デフォルトで 63 セクタから開始する ものが多い。63 は 8 (4096 を 512 で分割した値) で割り切れないため,ここに問題が発生する。Windows ユーザならば Western Digital のツール を利用して,問題のあるディスクのデータアライメントを調整することが可能だが,それ以外のオペレーティングシステムのユーザはインテグレーションテストの一部としてパーティションテーブルのレイアウトを確認し,必要に応じて修正する必要がある。
いずれにしてもハードウェアの最大性能を引き出すためには,パーティションテーブルからファイルシステム全体,ソフトウェア RAID や 論理ボリューム管理 にいたるまで,関連する各レイヤでデータアライメントの妥当性を確認する必要がある。
この問題に関しては,より詳しい情報が Linux ATA Wiki の ATA 4Kバイトセクタ問題 のページに紹介されている。Red Hat のエンジニア Karel Zak 氏は,パーティショニングとファイルシステムユーティリティの動作に関する要約を Linux カーネルメーリングリストに投稿 している。氏の Red Hat での同僚である Mike Snitzer 氏も I/O Limits: block sizes, alignment, and I/O hits というタイトルでドキュメントを書いている。さらに Oracle の Linux エンジニア Martin K. Petersen 氏による資料 Linux & Advanced Storage Interface も一読の価値がある。
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信