2012年1月25日水曜日

クラウドとはなんぞや


ちょち最近クラウドについての話題がGoogle+で出てくるんで書いて見た。
長文すまん。

■仮想化の流行
ここではCPUの仮想化、サーバの仮想化に絞って説明する。簡単に言えば「一つの物理サーバ上で複数のOSを同時に動かす」事である。この仮想化が流行ったのは以下の理由だ。

  • CPUの性能向上手段がマルチコアに切り替わった
  • 従来のプログラムの多くがマルチコアを活用しきれない

今までのCPUはコア自体を改善する事で性能向上を果たしてきた。その為多くのプログラムは1コアを前提として作成された。それでもCPUのコア性能がどんどん改善された為プログラムを放置しておいてもプログラムの処理速度は向上していった。しかし最近になりCPUのコア改善によるCPUの性能向上が頭打ちになった為、CPUは出来るだけ沢山のコアを詰め込む事で性能を向上させる手段に出た。多くのプログラムはマルチコアを想定して作られていないので、沢山あるコアを活用出来ず、プログラムの処理速度は向上しなくなってしまった。簡単に言えば8コアあっても1コアしか活動していない状況になってしまったのだ。
8コアあっても1コアしか活動してないのであれば非常にもったいない。元が取れていない。

そこで従来のサーバを仮想化し、8コアの物理サーバに8個の仮想サーバをぶち込めば、CPUコア全てを使い切る事が出来る、と考えて始まったのが仮想化の流行である。更に言えば8個の仮想サーバはそれぞれ役割が違うだろう。それぞれの仮想サーバが高い処理能力を必要とする時間がずれていれば、8コアじゃなくて4コアでも充分かもしれない。であれば8コアの物理サーバに16個の仮想マシンを入れる事も可能である。
極端な話を言えばそれまで100台の物理サーバで運用していたサーバ群を仮想化して5台の物理サーバ上に集約する事も可能な訳だ。

■過剰集約問題

しかし場合に依っては「100台のサーバ群の総合性能≒5台のサーバ群の総合性能」なパターンが生まれる事がある。生まれる理由としては以下の様なモノが考えられる。

  • 無計画な集約
  • 仮想化環境への追加投資が出来ない為の過剰集約

これを防ぐには以下の対策が必要である。

  • 最大負荷時を想定した仮想化環境の準備
  • 仮想化環境利用の制限

この様な対策をする位であれば仮想化による集約を行わない方が良い。前者の対策をとる場合、仮想化対象の物理対象の総費用より仮想化環境構築用のサーバの総費用の方が高くなる可能性すらある。

■余剰リソース問題
過剰集約が怖いので少し余裕を見て10台の物理サーバを仮想化し5台のサーバに集約したとする。が、しかし予想以上に仮想サーバは利用されず効果な仮想化用物理サーバが遊んでしまい投資コストの回収が出来なく成ってしまう。

※投資コストの回収・・・高いモノを購入した後それをシコタマ使って元を取る事。投資コストが回収出来ないといった場合、それは高いモノを買ったはいいけど余り使ってない状態になってしまう事。

■仮想化からクラウドへ
そこで以下の様なパターンが生まれてくる。
社内のサーバの仮想化による集約は成功した。しかしリソースが余っている。もったいない。何かいい方法はないか
まてよ?この余剰リソースを外部に有料で貸しだそうか。そうすればサーバの稼働率も上がって投資コストも回収出来る上に儲かるぞ
まてよ?儲かるんであれば大規模な仮想化環境を用意してその上の仮想リソースを販売すればこれはビジネスになるんじゃないか?
しかも利用者は、必要な時に必要なだけのリソースを私から借りればいい。初期コストはゼロだ。
 これを実践したのがクラウドサービスである。

■クラウドの境界線
日本国内では「仮想化すればクラウド」と誤認される事、誤認させる記事や情報が多いが、仮想化は飽くまでクラウド実現の一要素に過ぎない。仮想化とクラウドは別ものである。具体的に言えば以下の通りだ。

・仮想化用の物理的サーバを保有或いは確保した時点でそれはもうクラウドではなくなる。


「本当のクラウド」の利用者は自分達で物理サーバを用意する事はない。つまりこの時点で国内で推進されようとしている「自社内に作成するプライベートクラウド」は否定される訳だ。

・必要な時に必要なだけリソースを借り、不要な時は不要なリソースを捨てる事が出来、そしてやめたい時は即座にやめる事が出来なければクラウドではなくなる。


この時点で課金単位が月次、週次、日次であるサービスは否定される。人間の生活サイクルを考えた場合サーバの負荷の変動は一日毎にサイクルしていくだろう。であれば課金単位は時間単位であるべきである。究極の所、理想は秒単位であるが手間を考えたらやはり時間単位に落ち着くだろう。
同時に時間単位課金であれば、リソースを借りる速度(申し込みしてから実際にリソースが渡されるまでの時間)が1時間以下である必要がある。「今日申請したら明日利用出来ます、来週から利用出来ます、来月から反映させます」なぞというのは問題外だ。

仮想化ではこの様な事が出来ない。
仮想化によるサーバ集約だけではここまでは出来ない。
プライベートクラウドではこれを実現出来ない。
つまりここクラウドの境界線である。

■クラウドの真髄
イノベーションとはそれまで出来なかった事が出来る様になる事である。世に言うイノベーションを例に挙げると例えばテープに対するCD、CDに対するMP3とか。
例えばCDはそれまでテープでは不可能だった瞬時の頭出し、精確な曲送りを可能にした。
例えばMP3はそれまでCDでは不可能だった自由な曲の組み合わせ、移動の簡単さ、バックアップの簡単さ、再生の簡単さ、保存の簡単さを実現した。

ではクラウドがイノベーションである点は以下の通り。

  • 従来では保持出来なかった様なリソースを利用する事が出来る
  • 不要なリソースを保持する必要がない

どちらも従来の社内サーバ環境で実現する事は出来ない。同時に仮想化による集約を行っただけでは実現する事が出来ない。
クラウドでなければこれらのメリットをもたらす事が出来ないのだ。

例えば分散処理を考えてみよう。ある会社で給与計算が分散処理で行えたとする。ここではAmazon EC2をモデルに話をする。

さて給与計算は基本的に一ヶ月に一回だ。
なので30日中「給与計算をする為に必要なリソース」は一日だけであるとする。であれば残り29日間は給与計算の為のリソース(給与計算をする為のサーバ)を持っている必要はない。つまり費用はゼロ円である。

「さーて今月は特に急いでないから計算に一日かかってもいいや」と成れば、「性能は低いが一時間辺りの利用料も格安のクラウド上の仮想マシン」を一日借りて計算すればいい。
「やばい!明日給与支払いなのに計算してねぇ!後12時間しかない!ええい多少金かかってもいいから確実に終わらそう!」と思えば「性能は高いが一時間あたりの利用料金も高いクラウド上の仮想マシン」を複数借りて一期に分散処理してしまえばいい。

勿論給与計算が終わったらそれらのリソースを解放する。そうすれば再びコストはゼロだ。
そしてこのコストがゼロに出来る、まぁ精確に言えば不要な時はコストを極小化出来る、という事がクラウド最大のメリットだと思う。これは従来の物理サーバ購入では絶対に実現しえない事である。

■クラウドの定義
最後にまとめ。クラウドと呼ぶに値するサービスが備えるべき条件

  • 初期費用がゼロである
  • 利用した分だけ課金される(金さえ払えば無尽蔵にリソースを利用出来る)
  • 下院単位は最低でも時間単位である
  • 利用者からみて無尽蔵に見えるだけのリソースを確保出来ている
  • リソースの要求をしたら遅くとも1時間以内に利用する事が出来る

と言った所ですか。

2012年1月19日木曜日

Sphinxのバージョンアップをする

Sphinx1.1から1.1.2に上げた時のメモ。

Sphinxの最新版を手に入れる。PythonのこのページからDL出来るっぽい。

■事前にやる事
/usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg/
の中にあるthemeとか加工したソースとかを待避させておく事。

■旧Verの削除と新Verのインストール
sudo rm -fr /usr/local/lib/python2.6/dist-packages/Sphinx-1.1-py2.6.egg
wget http://pypi.python.org/packages/2.6/S/Sphinx/Sphinx-1.1.2-py2.6.egg#md5=d35db7a8ee62dd55522bca523954baa9
sudo easy_install Sphinx-1.1.2-py2.6.egg
終わり。

2012年1月18日水曜日

今日のsphinxメモ

sudo vi /etc/apt/sources.list

deb http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main
deb-src http://ppa.launchpad.net/vineuser/ppa/ubuntu oneiric main

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C95CAFC

sudo add-apt-repository ppa:vineuser

sudo aptitude update

sudo apt-get install texlive texlive-base ptex-base ptex-bin dvipsk-ja xdvik-ja ptex-jisfonts gs-cjk-resource jmpost dvipdfmx texlive-math-extra okumura-clsfiles jbibtex-bin mendexk texlive-latex-extra nkf dvipng python-software-properties python-sphinx

2012年1月17日火曜日

SphinxでHTMLでもPDFでも見やすい文書を一発で作る

昨年の秋位から Sphinx を本格的に使ってきたので色々メモした事、やった事をまとめて見る。Whyの部分は後で拡充するかも。

後これは俺が買って考えた事なので、これよりいい方法とか知ってる方いたら是非に教えてください。マジで。ホントに。
尚Sphinxを使える用にして、PDFまで出力出来る様にする方法は Sphinxとrst2pdfの「domains」がないよエラー を参照してください。


■やらないといけない事
取り敢えずやらないといけない要件は以下の通り。
  1. HTMLはHTMLで見やすく。PDFはPDFで見やすく。
  2. PDFは各章に通し番号を振る。HTMLは振らない。
  3. PDFは見出し必須。しかし見出しに載せる深さは2番目まで
  4. 内容的に同一の文書を使い回す場所がある。
これに加えて、HTMLとPDFの両方を作る場合以下の問題もあった。(今はもう Sphinx とか rst2pdf 側で対応してるかもだけど。)
  • HTMLを重視する場合、toctreeを使えば1ページに見出しだけが全てそろうので目的のページを探しやすく移動しやすい
  • PDFの場合、toctree を使って書くと章の番号を振るのがおかしくなる。
  • toctree はリンクになってしまいリンク先のページは個別で評価、変換されるっぽいのでPDFの場合だと章段落の程度がおかしくなる
  • include を使えば多数のファイルをマージして(1ファイルにして)から評価変換される用なので章段落の程度がおかしくならない。しかしHTMLだと一個のHTMLが巨大化してしまい死ぬほど見にくい。
つまり toctree は HTML と相性が良く、include は PDF と相性が良い。


■HTMLとPDFとを分けて考える
という事で「HTML用のRootドキュメントとPDF用のRootドキュメントを分ければいいんじゃね?」と考えて、調べてみたら出来るっぽい。Sphinxの conf.py の以下の場所の「indexPdf」の部分を変更する。
pdf_documents = [ ('indexPdf', 'Manualタイトル', u'Manualタイトル', u'Author', 'manual'), ]
初期値だとHTMLのと同じ奴に設定されてるけど、ここを変更するとPDFを作成する際はここで指定されたファイルをRootドキュメントにして作成してくれるようになる。こうしておけば make html pdf って一個のコマンドで違う構成ファイルを元にしたHTMLとPDFとが同時に作れる様になる。


■RSTファイルの構成
次に実際に利用するRSTファイル群は以下の様な構成に成っている。
  • index.rst ・・・ HTML用のドキュメント構成。ページ構成のRSTファイルを toctree で記述。
  • indexPdf.rst ・・・ PDF用のドキュメント構成ページ構成のRSTファイルを include で記述。
  • page.rst ・・・ 章構成。実コンテンツの本体。基本的に重複のない文書を書く。HTML用もPDF用も共通。 paragraph.rst を全て include で記述。 
  • paragraph.rst ・・・ 各パラグラフ。使い回す可能性のある文書はここに書いている。HTML用もPDF用も共通
index.rstは以下の通り
########
各章タイトル
########


.. toctree::
:maxdepth: 1


hoge
fuga
pugya
homu
indexPdf.rstは以下の通り。PDFの場合、各章の頭に数字を振りたいのでそのコマンドを先頭に入れておく。
.. section-numbering::


########
各章タイトル
########


.. include:: hoge.rst
.. include:: fuga.rst
.. include:: pugya.rst
.. include:: homu.rst
Sphinx公式のセクション管理 にSphinxでのセクション管理の例が載っているけど、私は以下の様なルールでセクションを利用している。
ただしpage.rstに関してはかなり流動的。使い回す可能性のない説明であれば、一番したのパラグラフまで使う事もある。
  • # 部: オーバーライン付き ・・・ index.rst/indexPdf .rst で使用
  • * 章: オーバーライン付き ・・・ page .rst で使用
  • =, セクション  ・・・ page .rst、 paragraph.rst で使用
  • -, サブセクション  ・・・   paragraph .rst で使用
  • ^, サブサブセクション  ・・・   paragraph.rst で使用
  • ", パラグラフ  ・・・   paragraph.rst で使用


■ PDFでの改ページ処理
一応rst2pdfには自動改ページ設定機能があるがこれが結構微妙。ルール一辺倒なのでいやここは・・・って所でも改ページしてしまう。なのでこれを使わず、面倒だけど自分で改ページを指定する事にした。

まずconf.pyの以下の設定をコメントアウトして自動改ページを無効にする。
#pdf_break_level = 2
で代わりの改ページ指定は、改ページしたい所に以下の記述を加えておく。これを入れておくとHTMLの方では何も出力されない。だけどPDFを出力する時のみ改ページ処理が行われる。
.. raw:: pdf


PageBreak
なお私が作ったドキュメントではこのPDF用改ページコマンドをpage.rstに末尾に必ず追加している。


■DPFの目次管理
次にPDFでのページ管理。toctreeを使うと目次っぽいのが勝手に出来るけど、includeを使うとそれが生成されない。なので rst2pdf の機能を使って目次を生成する。
また目次を設定する際、上から2番目(1.1 インストール方法)までを目次に載せるように設定する。これを指定しないと全てのセクションが目次に載ってしまう。(例えば 1.2.3.4.5 注意 とか)。
その為に conf.py に以下の設定を追加する。
pdf_use_toc = True
pdf_toc_depth = 2
目次に載せるセクションの深さは数字で自由に変更出来ます。


■ただ一つの欠点
これでHTMLとPDFの両方が見やすくなったと思う。
ただ唯一新しい章を追加する際にindex、indexPdfの2つに記述しないといけない事が面倒だけど。

参考になるURL