Kyoto Tycoon のインストールメモ
Kyoto Tycoon のインストールメモ
AWS 環境だけど、root さえあれば特に変わるところ無し。
root 無い場合はディレクトリ指定が必要。
今回は指定しなかったので、そこはパス。root あると楽だわ・・・。
ちなみに、AMI は、これ使った。一番普通のやつだと思う。
amzn-ami-pv-2012.03.3.x86_64-ebs (ami-2819aa29)
手順はとても簡単だけど micro インスタンスだと
make に 20 分くらいかかる。micro じゃなくても make は
結構時間かかる。
必要なコマンドをインストール
gcc++ と make が入ってない環境だったので、インストール
sudo yum install gcc
sudo yum install gcc-c++
sudo yum install make
必要なパッケージをゲット
wget http://fallabs.com/kyototycoon/pkg/kyototycoon-0.9.56.tar.gz
wget http://fallabs.com/kyotocabinet/pkg/kyotocabinet-1.2.76.tar.gz
wget http://zlib.net/zlib-1.2.7.tar.gz
zlib のインストール
tar zxvf zlib-1.2.7.tar.gz
cd zlib-1.2.7
./configure
make
make install
cd ..
Kyoto Cabinet のインストール
tar zxvf kyotocabinet-1.2.76.tar.gz
cd kyotocabinet-1.2.76
./configure
make
make install
cd ..
Kyoto Tycoon のインストール
tar zxvf kyototycoon-0.9.56.tar.gz
cd kyototycoon-0.9.56
./configure
make
make install
cd ..
以上。
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
一個、「あれ？」と思ったのが、Kyoto Cabinet インストール中に出た
以下のエラー。
./configure
#================================================================
Configuring Kyoto Cabinet version 1.2.76.
#================================================================
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking how to run the C++ preprocessor... /lib/cpp
configure: error: in `/root/kyotocabinet-1.2.76':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
[Linux]confgureでC++ preprocessor "/lib/cpp" fails sanity check | うえちょこ＠ぼろぐ
で原因判明。c++ コンパイラ入らないのか・・・。
手元の環境では、これを参考に
してあげると無事 ./configure 通った。
ldconfig
もう一個。インストール直後はライブラリにパスが通ってないので、
Ubuntuにkyoto tycoonをインストールしてみた。 - メイクミラクル 〜大逆転〜
の ldconfig あたりの手順を実行する必要がある。(手抜き)
DR について
データ欠損ゼロを実現するためには同期コピーが必須となる。
(中略)
一般に、同期コピーが適用可能な距離は100km以内とされている。これ以上の遠距離の構成では、複数のログやトランザクション情報をまとめて転送するなど、データ転送遅延時間の影響を最小化する工夫が必要となる。また、WAN最適化コントローラなどを適用し転送遅延時間を削減することも有効だ。
システムの要件によっては、データ欠損ゼロを保障する同期コピーのリモートサイトを100km以内の近郊に置き、災害直前のデータ欠損をある程度許容する非同期コピーのリモートサイトを遠隔地に置く3データセンター方式も有効である。
Part4 ディザスタリカバリ | 日経 xTECH（クロステック）
SnapMirrorは、元々ディザスタリカバリー（災害復旧）用のミラーをリモートサイトで作成することを目的とした機能です。
NetApp - Tech OnTap - NetAppの統合データプロテクション：最適なデータ保護ソリューションを選択する方法
LANケーブルや光ファイバの中を信号が伝播する速度は，おおむね 1kmあたり5マイクロ秒とされています。
(中略)
東京から大阪まで光ファイバを敷設した場合，直線距離なら400km程度ですが，ケーブルは一直線に敷設できるわけではないので，ケーブル長としては1000kmくらい必要になると思われます。ということは，片方向で5ミリ秒ほどの遅延が発生しますので，RTTは10ミリ秒になります。
第2回 ネットワーク遅延と高速化：教科書には載っていない ネットワークエンジニアの実践技術｜gihyo.jp … 技術評論社
200km あたり 1ms。往復で 100㎞ あたり 1ms。よーするに、RTT は 100km あたり 1ms が目安か。
12年後のCAP定理: "法則"はどのように変わったか
12年後のCAP定理: "法則"はどのように変わったか
この記事すごい・・・。もう今まで見たことのないレベルのサマリでびっくり。中には過去に自分が表現したくて苦労した事がわかりやすく表現されている個所もありショック(笑)
原文は、Eric Brewer ご本人の著。
"3つのうち2つ"はいくつかの場面でミスリーディングです。まず、分割は滅多に起きないので、分割のない状態ではCやAは失われません。次に、同じシステムの中でとても細かい粒度で何度もCとAのどちらかを選択する場合があります。サブシステムによって異なる選択をすることもできますし、操作やデータや関係するユーザによって選択を変えることもできます。最後に、3つの属性は満たす/満たせないのふたつの選択肢しかないのではなく、度合いがあります。可用性は明らかに0%から100%まで度合いがありますが、一貫性にも多様なレベルがあります。分割耐性にも同様です。システムに分割があるかどうかについての意見の相違も含んだ度合いがあります。
12年後のCAP定理: "法則"はどのように変わったか
以下が原文
As the "CAP Confusion" sidebar explains, the "2 of 3" view is misleading on several fronts. First, because partitions are rare, there is little reason to forfeit C or A when the system is not partitioned. Second, the choice between C and A can occur many times within the same system at very fine granularity; not only can subsystems make different choices, but the choice can change according to the operation or even the specific data or user involved. Finally, all three properties are more continuous than binary. Availability is obviously continuous from 0 to 100 percent, but there are also many levels of consistency, and even partitions have nuances, including disagreement within the system about whether a partition exists.
感動。是非読んでほしい。
結果整合性の意外な適用場所
ブログを相当長いこと放置していたので、たまには生存確認をかねて、投稿を・・・。
お金が絡むところでは厳密な一貫性が要求され云々言うわけだけども、一貫性を妥協すると全てが得られる。少なくとも高い可用性とスケーラビリティーが。*1
以下のような CAP 定理に関する反証もあるけど、
While the impossibility proof of CAP is mathematically correct, it is based on assumptions that are too strict. By relaxing these assumptions, I found the solution presented here.
Guy's Blog: A CAP Solution (Proving Brewer Wrong)
「Proving Brewer Wrong」と言っている割には、「CAP の並立不可能性は数学的には正しい」と認めていて、反証だか何だかよくわからない。時間を味方に付ければ CAP が並立することはブリュワーだって否定していないだろう。*2
さて、本題の意外な結果整合性の適用箇所だけど、某大手銀行の Web システム。
- A 銀行の Web システムで自分の口座にログインして、B 銀行の自分の口座に送金。
- A 銀行の Web システムで「着金完了」を確認。
- B 銀行の Web システムで自分の口座にログインして残高を確認するも残高は変わらず。（別にこの時点であわてたりはしない。ここで時差が出るのは普通の事なので。）
- B 銀行に電話して、Web 画面での残高を超える金額の送金指示を出す。
- 普通に受理される
- 送金完了を伝えられ、Web 画面で残高を確認するもまだ変わらず。
- 残高ではなく、入出金履歴を見ると入金と送金の履歴が。残高も変わっている。
- 再度残高確認画面に行くと、まだ残高は変わっていない・・・。
まあ結局しばらく待っていると残高は正しい数字になったけど、要するにこの銀行はどこで一貫性が取れている必要があるかをちゃんと認識していて、一貫性が取れている必要が無い部分については結果整合性が取れればよしとしているということになる。何の問題もないけど、銀行ってたとえ Web システムだろうが一貫性を重視してる*3んじゃないかっていうような思い込みがあって意外に思ってしまった*4。
この事例で学んだことは、「一貫性を保持する範囲を可能な限り絞り込む」こと。CAP 定理により、一貫性を重視することは他の2つの特性（可用性、分割耐性）のうちのどちらかを犠牲にすることにつながる。しかし、時間軸を考慮に入れるなら CAP は成立しうる。そして一貫性を保持する範囲を絞り込むならばさらに可用性と分割耐性を向上させることができる。
この辺は何々データベースの導入やら分散データストア製品の何々を導入したらという範疇に話が収まらず、要件定義、基本設計レベルでの考慮が必要になるため、アーキテクトと要件定義者双方に認識が必要。
*1:CAP定理 - Wikipediaを参照。
*2:「タイトルは釣り」かもしれない。コメントでも「同時に」がポイントとやんわり突っ込みが・・・。
*3:とはいえ、銀行間の送金にはすごい時間がかかる時がある。月末の送金はその日中に着金が完了しないことも経験済み。これは銀行のシステム間では「結果整合性」が実現されておりかつ、何の問題もないという良い例とも言える
*4:私は金融系のシステムなんて実質未経験みたいなものなんで、まったくの想像だけど、銀行がこういう結果整合性の概念を持っているのはある意味当然というか、実は彼らは結果整合性のエキスパートなのかもしれない。だって歴史的に金融系のシステムってバッチ処理中心に構築されてきただろうし、そのバッチ処理って、要するに非同期処理なわけだし。どこに一貫性が必要でどこに不要か、なんて事はいの一番に考える事なのかも知れない。
零細システム開発会社における「選択と集中」
- 作者: 大藤幹
- 出版社/メーカー: ソシム
- 発売日: 2009/12
- メディア: 単行本
- 購入: 4人 クリック: 125回
- この商品を含むブログ (9件) を見る
池袋のジュンク堂で偶然手に取った本書。再利用性のたかいCSSのデザインやら、コツの様な話かと思ったらそういう事だけでなく、入稿からスケジュール管理まで含めた牧野工房という会社のワークフロー紹介という、一風変わった本。まあ、会社の宣伝ちゃ宣伝かもしれない。
牧野工房という会社では、通常のホームページ制作会社とは異なり、デザインは完成しているという前提で、出来上がったデザインを入稿してもらい、それをHTML+CSS に落とす、という工程に特化している。
このような特化のため、結果的に数をこなせ、社内の共通化、ルール化、ワークフロー化が進み、ますます数をこなせる、という循環が働いている。
絵に描いたようなドラッカーの「選択と集中」の実践であり、同業の参入が予想されると筆者は書いているものの、ブランド化に成功すればライバル不在になりそうな商売である。
余談だけど、私自身はこれと同様のことを零細のソフトウェア開発会社に所属するエンジニアにもたびたび見ている。（まあウチもそうなんだけど）
彼らの中には、数ヶ月以下という、非常に短期のスパンでコーディング、テストのみを10年近い歳月にわたってやり続けたものまでおり、「Eclipse でソース書いてるはずなんだけど、横で見ていて何しているのかわからない」というレベルに達している人が実在する。
彼らは設計書がなかったり、むちゃくちゃだったりしてもうまくそれを客から聞き出して形にする技術も兼ね備えていたりもするのだ。私などは関心させられることしきりなのだけど。
なかなかこういったことを強みとしてブランド化に成功している会社に出会ったことはないし、オフショア化が進む中、海外勢がこの戦略をとった場合、とんでもないレッドオーシャンに叩き込まれる可能性もなくは無いが（笑）、いくらでも差別化の方向性はあるし、ぜひどこかやってくれないかな。
Web サイトのクライアントサイドに徹底的にこだわる
Web サイトの高速化は、サーバサイドの対処ばかりが実施されることが普通なように思いますが、単純なリクエスト-レスポンスであれば、待ち時間の80%はフロントエンドの処理に費やされているらしい。
ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
- 作者: Steve Souders,スティーブサウダーズ,武舎広幸,福地太郎,武舎るみ
- 出版社/メーカー: オライリージャパン
- 発売日: 2008/04/11
- メディア: 大型本
- 購入: 32人 クリック: 676回
- この商品を含むブログ (125件) を見る
よく言われるような「JavaScript は HTML の最後に記述しない」等の基本的なところから、DNS ルックアップの減らし方といったちょっと高度なところまでクライアントサイドに着目して高速化を追及している。
で、上記の続巻が先日翻訳されたんだけど、
続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス
- 作者: Steve Souders,武舎広幸,福地太郎,武舎るみ
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/04/10
- メディア: 大型本
- 購入: 20人 クリック: 351回
- この商品を含むブログ (29件) を見る
大幅に値上がりしており、買うかどうか悩む。非対応ブラウザの関係から、なかなか使いにくい gzip圧縮転送や、サーバープッシュの Comet の解説など、今風の話題が多くて興味は惹かれるんだけど。Comet はサーバ側の課題も多くて、面白い技術だと思っている。
