USP MAGAZINE

秋 で す ね。 ぶ ど う 狩 り や シ ェ ル ス クリプト で 夕 涼 み。

特集

軽量言語
http://www.usp-lab.com/LECTURE/CGI/LECTURE.CGI
ǡ
ȏǴǚÁ
ࢬܹ‫ރ‬
սਖ֦

も充実中！
続々と新講座K1

コマンド学習編

K2

シェルスクリプト学習編（帳票・バッチ処理）

K3

シェルスクリプト学習編（ウェブアプリケーション処理）

K4

ユニケージアーキテクチャ編

K5

ユニケージ開発環境セットアップ編

K6

システム運用・管理編

K7

プロジェクトマネジメント・人材育成編

KSQL

SQL エンジニアのためのユニケージ活用編

KSTAT

ユニケージにおける統計コマンド編

UNIX 初心者のための講座などもご用意しています。
技術の草原で百獣の王を目指す
エンジニアたちの新感覚トークライブ！

http://techlion.jp/

上記のサービス内容は 2014 年 8 月現在のものです。
最新の情報は弊社ホームページにてご確認ください。

ISBN 978-4-9048-0711-8
C3455 ￥500

USP 研究所
定価（本体 500 円＋税）

2014 Septembert vol.17

開発プロジェクトの進め方まで、ユニケージエンジニアとしてのトータルスキルを習得できます。

mber
Septe

17

¥500

TechLION 再録

小山哲志×角谷信太郎×鈴木たかのり×
前島有貴×和田裕介
本音バトル！ LL とイベントとコミュニティと！

ユニケージ開発手法
コードレビュー
Artwork created by Koji Ishizuka. © 2012 Zie's Bank .Co,. LTD All rights reserved.

ユニケージ開発手法教育講座

使用方法などをハンズオン形式で具体的に学べる講座です。UNIX の基礎からユニケージ開発手法による

9

Lightweight Language が世界を楽しくする

ǋ¯ǴǚÁǡǑȜǡǴ
ƉǂƝŸƠƕƸȏ

「ユニケージ開発手法教育講座」は、ユニケージ開発手法におけるデータ管理の方法や、オリジナルコマンドの2014Vol.

2014 September vol.17

C o n t e n t s
04

特集

軽量言語

Lightweight Language が世界を楽しくする

16

ユニケージ開発手法
コードレビュー 第 6 回
大内智明

21

未来に活きる！ 現場で使える！

40

白羽玲子

42

47 Open usp Tukubai

おためし on AWS 第 2 回

24 「シェル芸」に効く

AWK 処方箋 第6 回
斉藤博文

28

坪和樹

50 組織文化を変える汗と涙の物語

人間とコンピュータの可能性

アジャイル改善塾

大岩元

山海一剛

第5 回

第 17 回

30 シェル芸勉強会後追い企画

Haskell でやってはいかんのか？第 6 回
上田隆一

34 Linux 女子部誌上講座

リナ女のたしなみ 第 2 回
平愛美

36

スズラボ通信 第9 回
すずきひろのぶ

データモデリング 第 7 回
熊野憲辰

縁の木、育てよう 第 4 回漢のUNIX 第14 回

後藤大地

52

ユニケージエンジニアの作法
第 11 回

松浦智之

58

りゅうちの工作員日記 第 6 回
りゅうちてつや62 「医は仁術なり」 シェル魔人／編集後記ൈ৯ߝ၁
Lightweight Language が世界を楽しくするAWKECMAScript
ActionScript
JavaScript
JScript
Lua
Perl
PHP
PythonRuby
ShellScript
4

USP MAGAZINE 2014 Septemberൈ৯¢ߝ၁ࠡࡍ

ࠡࡍ
Tcl 「軽量言語」（Lightweight Language、LL）とは、ソー
修正、実行が容易とされるプログラミング
VBScript スコードの作成、言語の総称です。この10数年の間にバージョンアップを重ね、国内外でユーザー数を増やしています。言語系イベント
Clojure の数や規模の拡大がそれを物語っているでしょう。
軽量言語の定義や該当する言語の種類については諸説あり
Curl ます。
しかし、「比較的短期間に習得することが可能」「アプ
・運用現場で活用され、利用者の仕事のGo リやシステムの開発
負担を軽減するのに役立つ」「利用するユーザーのコミュニ
Groovy ティがあり、デバッグやローカライズへの貢献がなされている」「メンバー間で効果的な学習方法や使いこなすコツにつHaskell いて日夜研究が進められている」̶̶
などの共通する特徴が存在します。
JavaFX Script 本特集では始めに、6/28に開催されたTechLION vol.17
をレポート。言語系コミュニティやイベントの舞台裏に迫りPowerShell ます。それぞれの自負とコミュニティへの愛、相互のリスペク
また今回、日本UNIXユーザ会のScala トを感じ取ってください。
法林浩之さんの協力を得てLLの歴史、いま注目株の言語
LLが支持される本当の理由とは何か、
そし
Scheme をまとめました。
て、その将来像は。本記事から見えてくるはずです。
5

Lightweight
Languageの歴史
written by 法林浩之（日本 UNIX ユーザ会）
Lightweight Language（LL）という概念や、それに類する言語はどこで生まれ、どのような発展を遂げてきたのだろうか。本稿ではLLの起源から日本への伝来、さらに各種言語および言語コミュニティの歴史を概観する。

も定着しなかったが、日本の LL イベントは毎年コンスLL の起源

タントに開催を続け、またそれまでになかった「プログLightweight Language という単語が初めて使われラミング言語の枠を超えた交流」を生み出したことでたのは、2001 年 11 月に米国の MIT で行われた「LL1:

多くの注目を集めるムーブメントとなり、概念として定Lightweight Languages Workshop」 であるとされ

着した。

*1

ている。
翌年に行われた LL2 *2 では Ruby 作者のまつもとゆ

LL イベントに登場する言語の変遷

きひろさんも講演している。
イベントの Web サイトには LL についての厳密な定LL イベント開始以降の LL の歴史は、イベントに登義は記述されていないが、まつもとさんは講演の中で場した言語や実施されたセッションを振り返ることで、「Lightweight Language とは、人間がより少ない『脳ある程度概観できるだろう。ここではまずイベントに登力』でプログラミングできる言語である」という見解を場した言語を振り返る。

述べている。

初年度（2003 年）は Perl、Python、PHP、Ruby

つまり、無駄な労力を費やすことなくプログラムを書の 4 言語でスタートした LL イベントだが、評判を聞きくことができ、高い生産性をもたらす言語、というようつけたのか 2 年目以降は俺も俺も的に出場言語が増加

な意味合いであろう。

した。記録を見ると、2004 年は 12 言語、2005 年も11 言語、2006 年は 16 言語、2007 年に至っては 23

日本への輸入と定着

言語も登場していて、この年がもっとも出場言語数が多かったようである。

日 本 に お け る Lightweight Language の 初 出 は、

2008 年以降は、出場言語数という観点では徐々2003 年 8 月に行われた LL Saturday *3 である。もとに沈静化に向かっている。その要因のひとつとして、

もとは jus とアスキーで Ruby のイベントを企画してい

RubyKaigi *4 や YAPC *5 のような各言語コミュニティにたのだが、国内には Ruby だけでなく Perl も PHP もよるイベントが始まり、各言語に特化した話題はそちら

Python もユーザコミュニティがあるので、声を掛けてに移行したことと、小規模なコミュニティや勉強会であ合同でイベントをやろうという話になったものである。

れば簡単に実施できるようになり、LL イベントのよう

ここで、このイベントにふさわしい名前を考えていたな場を利用する必然性がなくなったのではないかと推ところに米国版 LL イベントの話を聞き、近い方向性を測している。

感じたのでイベント名称に Lightweight Language を冠することにした。
米国版 LL イベントは 2 回で終了し、LL という言葉
12 USP MAGAZINE 2014 September

LL イベントのセッションにみる技術の推移ൈ৯¢ߝ၁ࠡࡍ
表 1: 各年の技術を象徴するセッション
年
2003

タイトル

解説

!MM͂΂ήΐͿ·Πঐ࢜!!

QfsmȂ
QzuipoȂ
QIQȂSvcz͈΂ήΐͿ·Πঐ࢜ίυΈρηϋΈ਀༹͞৘௡
ͬ๤‫̹̱ڛ‬ȃ

2004

MM͂cmph2005έτȜθχȜ·చࠨ!

έτȜθχȜ·̭͈͜ා̪̞̥̩ͣͣ͢ঀ̠̹ͩͦͥ̈́̽͢ͅȃ

2006

MḾ‫۾‬ତίυΈρηϋΈ!

Ibtlfmm͈̈́̓‫۾‬ତ߿࡞ࢊͅಕ࿒̦ਬ̹̭̽͂́͘৘ঔ̯̹ͦȃ

2007

WNऌ!!

Kbwb!WN͞/OFU۪‫͈́ޏ‬MM͈၌ဥ༹ͬત̱̹ٚȃ

2008ࡣ̞࡞ࢊȂ૧̱̞࡞ࢊ!!

MMWN͂FDNBTdsjqu͈ੜၑࠏ̞݈̾̀ͅა̱̹ȃ2009ളͥଲ‫̥ͤ͊׌͉ۼ‬Hpphmf!Bqq!Fohjof͞Xjoepxt!B{vsf̈́̓·ρ;Ρષ͈́ίυΈρηϋ
Έ̞݈̾̀ͅა̱̹ȃ

2010

MḾέͻΐ΃σ!΋ϋάνȜΞͻϋΈ

2011

KbwbTdsjquส࿂჋ᦞ!

2012‫ࠑ͈̻̹ؠ‬௽എiphfiphf͉ই̹̥̺̽͊ͤ͘Ȋ

2013

Jogsbtusvduvsf!bt!MM̭͈̥ࣼͣήυΈ̦ၠ࣐̱ই̹͛ȃ

Hbjofs͞Bsevjop͈̈́̓δȜΡͬMḾଷࢄ̳ͥ਀༹ٜͬ୰̱̹ȃ̜ͣͥ͠໦࿤́ঀ̠̹ͩͦͥ̈́̽͢ͅKbwbTdsjqu̞݈̾̀ͅა̱̹ȃࠑ௽എͼϋΞΈτȜΏοϋ͈̈́̓৾ͤழ͙ͬત̱̹ٚȃDifg͞Qvqqfǘ̓MMͬဥ̞̹ͼϋέρࢹ଼‫ۯ‬ၑ̞݈̾̀ͅა̱̹ȃ

過去の LL イベントのプログラムを眺めてみると、そい Perl、PHP、Python、Ruby を「四大言語」と称の時代の最新技術やプログラマー達の関心事が反映さしてきた。
その頃の JavaScript はブラウザの動作に少し動的れていることがわかる。
ここでは各年のプログラムから当時の技術動向を象な変化をつける程度の言語という扱いだったのだが、徴するセッションを列挙すること（表 1）で、LL 関連

2005 年ぐらいからの Ajax の流行により新たな価値の技術の変遷をたどる。

を見出され、Web サービスに欠かせない言語としての地位を確立した。さらに近年は Node.js のような十数年の間に変わったことサーバー側での利用や、スマートフォン用のアプリ
ケーション開発にも使われるようになった。

LL イベントを運営して 12 年になるが、その間におそらく今では四大言語を超えてもっともユーザー数の多い LL であろう。

LL を取り巻く状況は大きく変化した。
中でも顕著と思われることを 2 つ取り上げたい。

これからの LL は

★ LL の業務ツール化
LL イベント開始当初、業務における LL の用途としては、Perl による CGI や PHP による簡単な Web

LL イベントは「明日のプログラミングが楽になるよう

アプリケーション、およびシェルや Perl などによるに」というのがひとつのテーマであると私は考えている。

システム管理作業の自動化やデータ処理といったとこ

そのために新しい言語やツールを使ってみたりするろが中心で、分野が限られていた。当時、「LL を仕事

わけだが、ここで、10 年前の LL と今の LL は同じなに」という、どうすれば業務で LL を利用できるかをのか、そして今の LL はこの先も LL で在り続けられ議論するセッションを行ったこともある 。

るのか、というのが最近の私の疑問である。10 年も*6

ところが、Ruby on Rails などのフレームワークを経てば新しい言語が台頭し、取って代わられることも用いた Web サービス開発が一般化すると、LL を業あるだろうと思っていたのだが、今のところはまだそ

務で利用することが普通に行われるようになった。

こまでには至っていないようである。しかし 10 年後

特にそれまで業務での利用シーンがなかなか増えな
かった Ruby の普及が一気に進み、今では Ruby ではどうだろうか。
このイベントに登場する言語に新陳代謝があるのか仕事をする人が普通に存在するようになったのは隔世

どうか、これからも注目していきたい。

の感がある。

*1：http://ll1.ai.mit.edu/★ JavaScript の台頭
もうひとつの大きな変化は JavaScript の台頭である。LL イベントでは初年度から登場しユーザーも多*2：http://ll2.ai.mit.edu/*3：http://ll.jus.or.jp/lls2003/*4：http://rubykaigi.org/*5：http://yapcasia.org/*6：http://ll.jus.or.jp/llw2004/program.html

13

オ ト ココマンドを極めるその先へ

BSDコンサルティング株式会社 取締役 最高技術責任者 後藤大地

題字「漢」 小林 勇

第十四回

UFS ファイルシステムの特性を知る
FAT32 と比較する

フラグメントとシリンダ
グループは SSDでは逆効果？

1

は、HDD の「物理特性」に合わせて導入された機能ということになる。

登場初期の UFS は、大雑把に捉えると 3 つの区切り●フラグメンテーション：転送速度を引き上げた場合しか存在しなかった。ディスクの情報を納めた「スーでもディスクのスペース面での使用効率が下がらない

パーブロック」、inode のデータを納めた「inode ブロッ

ようにする。

ク」、実際のデータを納めた「データブロック」だ。ス

●シリンダグループ：ヘッドが移動することで発生するトレージのサイズが大きくなってくると性能を引き上げ

遅延を回避するために、小さいグループをたくさん作っるためにブロックサイズを大きくするようになった。そてヘッドの動きがなるべく近場で収まるようにする。

うなると小さいファイルが巨大なブロックに収まること

SSD は上記の制約を受けないため、こうした機能はになり、実際には使われていない領域が増えることにむしろ動作を遅くする原因になっていると考えられる。

なる。これを回避するためにブロックの書き込み単位とSSD というデバイスに対しては、むしろ登場初期のシして「フラグメンテーション」が導入されることになる。

ンプルな UFS の方が高速化が期待できる可能性があUFS ではメタデータの更新（inode の書き換え）とデータの書き換えを実施するわけだから、ハードディス
クのヘッドは「inode ブロック」と「データブロック」

る。今回はそれを検証してみよう。

FAT32ファイルシステム

2の間を行ったり来たりすることになる。ストレージのサ「スーパーブロック」「inode ブロック」「データブロッイズが大きくなってくると、この行き来にかかる時間がク」しか存在しない頃の UFS の構造は、FAT ファイル

無視できないものになってきた。そこで UFS は「シリシステムによく似ている。FAT ファイルシステムの構

ンダグループ」という概念を導入する。一組しか存在

造はさらに単純で、「FAT」と「データブロック」のみだ。

しなかった「inode ブロック」と「データブロック」を、後に「スーパーブロック」に相当するブロックも追加さ

小さいサイズの『「inode ブロック」「データブロック」』

れ、細かい構造は違うが大枠の区切り方は近い。

の集まりとして捉えるようになる。この 1 つの集まり（単

シリンダグループを 1 つにした UFS を作ってベン位）を「シリンダグループ」と呼ぶ。ハードディスク上チマークを実施したいところだが、現在の UFS2 の実の「inode ブロック」と「データブロック」の位置を、
ヘッ

装はシリンダグループの使用が前提になっているため、ドの物理的な移動経路に近いところへ集約し、ヘッドのシリンダグループのサイズを変更する、個数を変える

移動に費やされる時間を短縮する高速化を狙った。

といったことが簡単にはできない。そこで、こうした回

つまり、現在の UFS が実装している次の 2 つの機能

36 USP MAGAZINE 2014 September

転円盤向けの機能が入っていない状態で、これまで実表 3.1
ブロックサイズ

フォーマットコマンド

4KB

ofxgt!.P!3!.b!43!.c!51:7!.e!51:7!.f!623!.g!51:7!.h!27495!.i!75!.j!92:3!.l!5:3!.n!9!.p!ujnf!.t!593455:71!0efw0hqu0t

4KB（SU）

ofxgt!.P!3!.V!.b!43!.c!51:7!.e!51:7!.f!623!.g!51:7!.h!27495!.i!75!.j!92:3!.l!5:3!.n!9!.p!ujnf!.t!593455:71!0efw0hqu0t

32KB

ofxgt!.P!3!.b!5!.c!43879!.e!43879!.f!51:7!.g!43879!.h!27495!.i!75!.j!76647!.l!5278!.n!9!.p!ujnf!.t!593455:71!0efw0hqu0t

32KB（SU）

ofxgt!.P!3!.V!.b!5!.c!43879!.e!43879!.f!51:7!.g!43879!.h!27495!.i!75!.j!76647!.l!5278!.n!9!.p!ujnf!.t!593455:71!0efw0hqu0t

表 3.2
クラスタ
セクタサイズ あたりのセクタ数

フォーマットコマンド

512B

2

CzuftQfsTfd>623!TfdQfsDmvtu>2!SftTfdupst>43!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>38373:892!GBUtfdt>31:8263!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

1KB

2

CzuftQfsTfd>2135!TfdQfsDmvtu>2!SftTfdupst>27!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>352283553!GBUtfdt>:45888!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

2KB

2

CzuftQfsTfd>3159!TfdQfsDmvtu>2!SftTfdupst>9!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>231697332!GBUtfdt>345715!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

4KB

2

CzuftQfsTfd>51:7!TfdQfsDmvtu>2!SftTfdupst>5!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>713:418:!GBUtfdt>69877!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

8KB

2

CzuftQfsTfd>92:3!TfdQfsDmvtu>2!SftTfdupst>5!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>41257619!GBUtfdt>25817!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

16KB

2

CzuftQfsTfd>27495!TfdQfsDmvtu>2!SftTfdupst>5!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>26184365!GBUtfdt>478:!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

32KB

2

CzuftQfsTfd>43879!TfdQfsDmvtu>2!SftTfdupst>5!GBUt>3!Nfejb>1yg1!TfdQfsUsbdl>74!Ifbet>27!
IjeefoTfdt>1!IvhfTfdupst>8647738!GBUtfdt>:31!SppuDmvtufs>3!GTJogp>2!Cbdlvq>3

験してきたようなブロックサイズ / フラグメントサイズを変更した場合にどのように性能が変化するかを FAT
ファイルシステムを使って実験してみたいと思う。

-m デバイスファイルで確認）。
FAT32 でのフォーマットには newfs̲msdos(8) コ
マンドを使う。セクタサイズは -S で、クラスタごと

FAT32 では、UFS のブロックに相当する（わけではのセクタの数は -c で指定できる。newfs̲msdos(8)ないのだが、似たような変更ができる）ものにクラス

コマンドは FAT12、FAT16、FAT32 のフォーマット

タがある。クラスタは 1 つ以上のセクタで構成される。

が可能で、-F でどのフォーマットを使うかを指定でクラスタとセクタがブロックとフラグメンテーションのきる。この場合は「newfs̲msdos -F 32 -S 512 -c

ような関係になっている（厳密にはだいぶ違う）ので、

1 デバイスファイル」のように指定することでフォー

この部分を変更しながらベンチマークを実施する。クラマットを実施できる。フォーマット時のオプション結

スタを複数のセクタで構成する方法は実装が安定して果を表 3.2 にまとめておく。

いなかったので、ここでは 1 セクタ 1 クラスタの構成で、セクタサイズを変更しながらベンチマークを実施した。

フォーマット3

ベンチマーキング4

これまで同様のベンチマークを実施すると次のページのような表とグラフが得られた。

まず比較として UFS2 で特徴的だったブロックサ

FAT32 でフォーマットされたファイルシステムは、イズが 4KB のケースと 32KB のケースについて、そUFS2 において最も性能が高いケースに匹敵、もしくれぞれ Soft Updates 機能が有効になった場合と無はそれを超える性能を発揮していることがわかる。

効になった場合、フラグメントのサイズがブロックの8 分の 1 の場合とブロックサイズと同じだった場合

結果と考察

5

のベンチマーク結果を取得しておく。それぞれフォー

SSD はその特性上、フラグメンテーションやシリ

マット時のオプションは表 3.1 のとおり（dumpfs

ンダグループを必要としないため、よりシンプルな37

表 4.1
ブロック /
フラグメントサイズ、
セクタサイズ（FAT32）

4KB/512B
4KB/512B（SU）
4KB/4KB
4KB/4KB（SU）
32KB/4KB
32KB/4KB（SU）
32KB/32KB
32KB/32KB（SU）
512B
1KB
2KB
4KB
8KB
16KB
32KB

シーケンシャル
書き込み速度[ バイト / 秒 ]265369633
85976941
32663:5:2
332171:39
72335573
59221137
58924226
311296142
94615217
289848718
37256427:
372735985
347739:4:
2:667:359
322856996

シーケンシャル
読み込み速度[バイト/秒]459473714
3:5473588
465287979
4545614:9
462911518
475594353
436757854
63:778112
3724:14632266721673818
641146:6:
6463246:3
6463:586:
64:523159

ランダムファイル
書き込み時間[秒]ランダムファイル
読み込み時間[秒]ランダムファイル
削除時間[秒]

55/44
38/93
64/77
34/26
93/15
41/76
273/64
4:/37
36/::
34/21
36/91
43/6:
61/63
7:/65
216/79

55/86
56/28
51/38
51/36
4:/89
4:/:2
52/57
52/95
61/62
56/15
53/34
49/::
49/5:
4:/33
52/91

35/31
3/33
42/99
3/66
4:/89
2/75
:8/62
3/12
9/83
7/49
:/12
21/:4
31/27
42/86
65/33

図 4.2 シーケンシャル書き込み速度 ↑高いほど高性能

図 4.3 シーケンシャル読み込み速度 ↑高いほど高性能

ファイルシステムの方がパフォーマンスを発揮しやす

味がないのだが、興味深い結果といえる。

いというのが、今回の結果から推測できる。今回のデータ処理などに特化したシステムを開発する場

ケースでは特に FAT32 のセクタを 4KB、クラスタに合、FAT32 もひとつの候補として検討できることにおけるセクタの数を 1 にした場合、シーケンシャルなる。特に SSD をベースとしたストレージで高速デーな処理でも、小さいファイルを大量に処理するようなタ処理を実施したいとなった場合、FAT32 は興味深ケースでも、どちらでも高い性能が出ている。UFS

い検討対象といえる。FAT32 では 1 ファイルあたりと FAT では実現している機能の違いゆえにまったくの最大サイズが 4GB という制限があるためビッグ同じレベルでパフォーマンスについて比較するのは意

データの扱いに難があるが、なかなかおもしろい。

38 USP MAGAZINE 2014 September図 4.4 ランダムファイル書き込み時間 ↓低いほど高性能

図 4.5 ランダムファイル読み込み時間 ↓低いほど高性能

図 4.6 ランダムファイル削除時間 ↓低いほど高性能

逆の視点から今回の結果を捉えると、UFS2 の提供て特定の状況やハードウェアに特化した変更を続ける

するさまざまな機能を実現しながら、FAT32（4KB セと、ハードウェアの構成が変わったときにすべてが役クタ）に匹敵する性能を発揮している UFS 32KB ブ

立たずになることがある。このため極端な最適化はせロック /32KB セクタ +Soft Updates 機能は良くできずに、次のような指針でソースコードを記述するのがているといえる。FAT32 には Soft Updates 機能に相ベターと言われる。
「シンプルな設計」、「クリティカ当する機能が存在しないため削除処理では UFS+Soft

ルパスを明確に」、「行き過ぎた最適化はしない」だ。

Updates の性能には及ばない。UFS からフラグメン

UFS は、回転円盤という物理特性に対応するため

トとシリンダグループの機能をそぎ落とした状態で、に「シリンダグループ」と、そのデータ転送特性に対Soft Updates 機能を有効にした場合、UFS ベースで応するために「フラグメンテーション」という概念をも FAT32 を超える性能を発揮する可能性がある。

導入したが、この概念を捨てて元に戻すと、SSD 向

6きのファイルシステムを作ることができる。その場合

クリティカルパスと最適化

ソフトウェアのパフォーマンスを引き上げようとしでも Soft Updates 機能や各種最適化機能はそのまま適用できる。

39

〜便利なコマンドをクラウドで使おう〜Open usp Tukubai
おためし on AWS

第2 回

AWS 性能評価 〜利用する前にコストを考えよう！
written by 坪 和樹

7月号から開始した本連載の第2回は、パフォーマンスの測定として「AWS+Open usp tukubai環境」の性能評価を行いたいと思います。第1回で“使える”環境ができあがったのに、性能評価を急ぐのはなぜ？ とお考えの方もいるかもしれません。実は、AWSを利用するコストを考える上で、性能評価が最も大切だと思われるからです。

なぜ性能評価が大切なのか？
Open usp Tukubai を利用する方々は、大規模なデータの集計やソートなどを行う機会が少なくないと提や tips をお伝えさせて頂きたいと思います。
★試験環境● OS は Amazon Linux

思います。例えば、UEC のサイト（usp engineers'

Redhat 系 列 の OS な の で、Redhat や CentOS

community site: https://uec.usp-lab.com/）には、と同等の性能が出ることを期待できると思います。

「商品部門 / 地域毎売数データの帳票作成」というシェ

ま た、AWS 環 境 を 便 利 に 使 う た め の CLI ツ ー ルルスクリプトのサンプルが公開されています。これは、が標準で用意されている等のメリットがあるため、商品の売り上げレコードを集計するというサンプルレ

EC2 インスタンス上における OS は Amazon Linux

シピになっており、実に 300 万行のテキストデータでをお勧めします。

も難なく集計できることが示されています。

● EBS(Elastic Block Storage) は、SSD タ イ プ

また、ご存知の通り AWS は 1 時間単位の時間課金（General Purpose）を利用となっています。つまり、起動直後に停止しても、12014 年 6 月に発表された、SSD タイプの EBS で

時間ぎりぎりまで使い切っても料金は同じです。EC2ある General Purpose を利用して検証を行いました。

インスタンスは性能によって料金が設定されており、このタイプではブースト機能があり、ブーストが無くその中でも高価な EC2 インスタンスには、大容量のなると I/O 性能が低下します。リリースされた直後に

SSD 一時ディスクや高速なネットワーク帯域など有用検証を行っているため、考察において十分ではない部

な機能が付いてきます。つまり必要なときに高性能な分もあるかもしれません。本番環境で利用する場合な

EC2 インスタンスを使えば、それだけ処理が早く終わ

どは必ず先に検証を行ってください。

るということを意味します。
一般的には、分散処理を行おうとすると対応に手間★ tipsがかかるかと思いますので、1 台のインスタンスだけ● AWS 環境は使い終わったら停止もしくは削除！

で処理を行うスクリプトであれば、すぐに検証するこAWS ではインスタンスの起動時間で課金されるとが可能です。そのためにも、手持ちのデータ量に対ため、できれば使わないときは落としてください。

して、どのくらいの性能を割り当てる必要があるのか

また、ディスクや固定 IP も課金体系が設定されていを知っておくことが大切なのです。

るため、再作成で良いものは都度削除して頂くのがEC2 インスタンスの費用対効果を高めるために、性能試験は必須だとご理解頂けたでしょうか。
●早速、試験結果を……の前に手続き型になってしまい恐縮ですが、いくつか前

無難です。

性能の比較
それでは、実際に比較を行った結果を図示します。
47

図 1：スクリプト処理を 100 回繰り返した時の合計時間

グラフの縦軸の単位は「時間」（h）

図 2：処理 1 回あたりにかかる平均、最小、最大時間

グラフの縦軸の単位は「秒」

比較のために、紹介させて頂いた「商品部門 / 地域毎とを確認した上で記載しておりますが、必ずこうし売数データの帳票作成」という UEC のサンプルレシ

た時間で処理が終わることを保証するものではあり

ピを利用させて頂きました。サンプルレシピの中ではません。何卒ご了承ください。

comma や keta といった Open usp Tukubai のコマ

ま ず、100 回 の 処 理 を 繰 り 返 し 実 行 し た と き のンドが利用されており、実際の利用シーンに近いので

合 計 時 間（ 図 1） で す。t2.micro → t2.small → t2.

はと考えて選択しております。

medium と 処 理 時 間 が 約 半 分 に な っ て い る こ と が分かります。これは割り当てられている CPU 性能★各 EC2 インスタンス毎の性能評価

がインスタンスタイプに応じて約２倍ずつ増えていグラフは、各インスタンスの種類（T2、M2、C3）

る こ と か ら 見 て も 妥 当 な 結 果 と 言 え ま す。 一 方 でにおけるサイズ（small、medium、large など）を比

m3.medium の性能が大きく t2.medium に劣ってい較したものです。EC2 インスタンスで、起動直後に必るように見えますが、T2 には無いが M3 で提供され要なアップデートやインストール、試験環境の構築をる機能（一時ディスクの割り当て等）もあるため、安自動で行った後、サンプルレシピを 100 回繰り返し実定した処理を提供する M3 が必要となる場面も多々行しました。

あるはずです。また、今回のサンプルは CPU がボト

なお、全ての EC2 インスタンスに対して複数回のルネックになっていたものと考えられ、コンピュート

検証を実施し、いずれの検証でも値に乖離が無いこ

リソースを多く使える c3.large において最も早い結48 USP MAGAZINE 2014 September図 3：各処理にかかったコスト

グラフの縦軸の単位は「ドル」

果となりました。
図 2 では、100 回実行した処理の各回について、処理

EBS ボリュームの PIOPS や最適化オプションがパ
フォーマンスチューニングに役立つかもしれません。

時間の平均（AVE）、最小（MIN）、最大（MAX）をグラ
フ化してみました。グラフからもお分かりのように、T2
インスタンスは処理速度にばらつきがあり、ブーストが無い場合に処理時間が長くなる傾向が見られました。

まとめ
T2 インスタンスは安価な価格設定となっており、最後に、各インスタンスを利用した今回の検証で消コスト面で優れています。ユースケースによっては処費したコストを計算し、比較してみました。図 3 は、理時間を厳密に計算する必要があるなど、T2 が使え

各インスタンスで検証を行った際のコストを示したもない場面もあるかもしれませんが、検証目的の場合にのです。T2 インスタンスは安価な価格設定のため、はかなり助かる局面もありそうです。

処理が長くかかった場合でも安く済んでいることが分

なお、今回の検証のために利用したサンプルレシピ

かります。また、適切なインスタンスを選ぶことでコ

では、入力として約 309 万行（106MB）のファイ

ストが 2 倍近くも違うことがあることが読み取れます。

ルを一度シーケンシャルに読み込みますが、出力は標

今回の検証で、T2 系の EC2 インスタンスでは、ブー準出力に吐き出すため、ディスクへの書き込みを行っスト機能により短時間で処理が終わる時もありますていません。

が、反面でブーストがなくなった後に処理時間が長く

また、マルチコア環境でも性能が十分に発揮されていなる傾向があることが分かりました。M3 インスタン

るように見える理由として、スクリプト内では帳票を加ス、C3 インスタンスでは安定した処理時間になって工するために、実に 25 ものコマンドをパイプラインでいることも確認することができました。

実行していることが挙げられると思います。パイプライ

UEC のサンプルレシピを 100 回実行したときのコンで繋がれたコマンドはそれぞれ入出力を受け渡ししストは、図 3 から分かる通り t2.medium が最も安価ながら独立したプロセスで動くため、マルチコア環境ででした。ただし、無料利用枠がある場合には数時間以も良いパフォーマンスが得られたものと思います。

上かかっても t1.micro で実行した方がコストがかからずお得かもしれません。

本稿の検証はあくまで一例ですが、指針なくクラウ
ド環境に一歩を踏み出すのはとても勇気が要ることでまた、今回の検証においては C3 系のインスタンス

す。今回ご紹介した検証結果が参考になり、読者の皆を利用すれば高速に処理が終わることが確認できまし様の不安が軽減されれば、また、Open usp Tukubai

た。注意点としては、コストが高いインスタンスを利環境と AWS を利用する一助となれば幸いです。

用すれば簡単に高速化することができますが、一定以上の高速化を求める場合には工夫が必要です。例えば49

USP MAGAZINE

秋 で す ね。 ぶ ど う 狩 り や シ ェ ル ス クリプト で 夕 涼 み。

特集

軽量言語
http://www.usp-lab.com/LECTURE/CGI/LECTURE.CGI
ǡ
ȏǴǚÁ
ࢬܹ‫ރ‬
սਖ֦

も充実中！
続々と新講座K1

コマンド学習編

K2

シェルスクリプト学習編（帳票・バッチ処理）

K3

シェルスクリプト学習編（ウェブアプリケーション処理）

K4

ユニケージアーキテクチャ編

K5

ユニケージ開発環境セットアップ編

K6

システム運用・管理編

K7

プロジェクトマネジメント・人材育成編

KSQL

SQL エンジニアのためのユニケージ活用編

KSTAT

ユニケージにおける統計コマンド編

UNIX 初心者のための講座などもご用意しています。
技術の草原で百獣の王を目指す
エンジニアたちの新感覚トークライブ！

http://techlion.jp/

上記のサービス内容は 2014 年 8 月現在のものです。
最新の情報は弊社ホームページにてご確認ください。

ISBN 978-4-9048-0711-8
C3455 ￥500

USP 研究所
定価（本体 500 円＋税）

2014 Septembert vol.17

開発プロジェクトの進め方まで、ユニケージエンジニアとしてのトータルスキルを習得できます。

mber
Septe

17

¥500

TechLION 再録

小山哲志×角谷信太郎×鈴木たかのり×
前島有貴×和田裕介
本音バトル！ LL とイベントとコミュニティと！

ユニケージ開発手法
コードレビュー
Artwork created by Koji Ishizuka. © 2012 Zie's Bank .Co,. LTD All rights reserved.

ユニケージ開発手法教育講座

使用方法などをハンズオン形式で具体的に学べる講座です。UNIX の基礎からユニケージ開発手法による

9

Lightweight Language が世界を楽しくする

ǋ¯ǴǚÁǡǑȜǡǴ
ƉǂƝŸƠƕƸȏ

「ユニケージ開発手法教育講座」は、ユニケージ開発手法におけるデータ管理の方法や、オリジナルコマンドの2014Vol.