コモディティサーバ戦略のパラドックス
今さら確認するまでもないが、サービスの成長に合わせてこまめにサーバリソースを追加し、負荷をうまく分散して処理していく戦略がスケールアウトで、図の上がこれを示す。 主に安価なコモディティサーバを使うイメージである。 一方、図の下は、最初から高価で高性能のサーバを買ってしまい、それをぎりぎりまで使い切って、あるタイミングでまた高性能のサーバを追加するイメージである。まぁ、一昔前まで当たり前だと考えられていたアプローチである。 上だと最終的に6台のサーバが、下だと最終的に2台のサーバがある感じである。 図中の青い部分が「買ってしまったけど使っていない」リソースであって、無駄なコストである。 上の方が、青い部分の面積は小さく、無駄なコストを省くことに成功している。スケールアウト戦略を選択する理由にはいくつかあるが、そのうちでポピュラーなものがこの「無駄なコストの削減」である。 しかしこのときサーバ
HTTPサーバにJava NIOは必要か
0x00. はじめに 筆者はJava製のWAF(Web Application Firewall)、Guardian@JUMPERZ.NETの開発とメンテナンスを行っている。元は自社のシステムを守るために（そして半分趣味で）作ったものだが、数年前にこれをコアのエンジンとしてさらに拡張し、SaaS型の商用サービス「Scutum(スキュータム)」を立ち上げた。 その後順調に顧客を獲得することができ、システムリソース的にも増強が必要となる段階などを経験した。Google、mixiやはてな等、さまざまな大規模サイトのインフラエンジニアの方々がインフラ設計に関する考え方などをインターネット上で公開してくれているおかげで、初期のシステム設計時に「将来的にスケールアウト可能なシステム構成にしておくこと」が重要であるということがわかっていた。その教えに従っていたおかげで、リソースの逼迫（ちなみに今回はCP
コネクションプールについて
「コネクションプールがなぜ必要か？」 まず上記の設問自体がおかしくて、コネクションプールが必要（あるいは適している）場面もあれば、まったく不要である場面もある。必ずしもコネクションプールは必要ではない。コネクションプールにはメリデメが存在する。銀の弾丸ではない。 コネクションプールという言葉から始まってしまうとRDBMSとかのイメージが付きまとってしまうが、これはもう少し抽象化して考えると、オブジェクトプールと呼ばれるデザインパターンのひとつとして捉えることもできる。 オブジェクトプールのメリットは大きく分けて以下の2つ。 ・初期化コストや廃棄コストが高いオブジェクト（データベースのコネクションやスレッド）を再利用可能にすることにより、レイテンシ、スループットやシステム負荷等を改善する ・システム中で使用されるリソース数の上限をコントロール可能にする。 ウェブのシステムのように、クライアン
Continuous Deliveryの時代とJava
かつてバージョン管理やCIなどが存在しなかった頃 人々は手作業で（FTPなどを使い）PHPファイルをアップロードすることで、本番環境へデプロイを行っていた 筆者はJavaプログラマだったので 「本番環境でバグが見つかっても、問題のファイルを修正してアップロードすることで、一瞬で修正できる」 というPHPの利点が非常にうらやましかった Javaだとjarに固めてアプリケーションサーバにFTPで上げて再起動する、みたいな感じで非常に面倒くさかったのだ しかし時代は経過し、「ユニットテスト等が行われた後でしか本番環境のファイルが変更されるべきではない」という考え方が常識となってきた こうなると、「手軽にちょちょいと問題を修正する」というPHPの良さは失われることになる ウェブアプリケーションを構成するファイル群が全体としてバージョン管理され、テストをパスしたファイル群のみが本番環境に到達できるの
Log4j 2にも採用されたLMAX Disruptorはなぜ狂ったように速いのか？
LMAXという会社はおそらくFX業者で、筆者はLMAXの開発者の講演を、InfoQの動画で何度か見たことがあった。 彼らは非常に特異な集団で、さしずめ「Javaのスピード狂」という感じだ。 印象的なのは、シングルスレッドで仕事を片付けることを強調している点だ。 「Javaならマルチスレッドで並列処理すれば性能が出ると広く思われているが、我々の仕事においてはシングルスレッドが最速だ」というような主張を何度も見た。 ゴールドマンサックスといいLMAXといい、やはり多額の金が動く会社でガチでJavaをやっている連中はカリカリにチューニングするため、技術的には非常に面白い。 彼らがコアのライブラリをOSS化してくれるというのは、金融業界を否定的な目で見る筆者からすると複雑だが、悔しいことに参考になる。 LMAX DisruptorはJavaのライブラリだ。Producer/Consumerパターン
自宅で働くJavaプログラマになって13年経過したのでメモ
当時は「SOHO」というキーワードで知られている、いわゆる在宅勤務。私は2002年頃からずっとやっていて… まぁ誰かの参考になる可能性もあるかと思ってメモします。 まず、私の在宅勤務がどんなものかを簡単に。 私は2002年頃に「株式会社ビットフォレスト」というスタートアップを立ち上げた、いわゆるファウンダーです。そのため、世の中の人が「在宅勤務」で想像するであろう「雇われている」形態ではありません。ここは非常に大きなポイントになると思います（要するに自分がさぼると、きっちりツケが廻ってくるという意味で）。 場所は横浜市の南の方で、「下永谷」という名前の、駅前に何もない場所でやっています。最近、ついに駅前にコンビニが出来ました。どうでもいい。 在宅勤務を始めるよりも前に結婚しており、一人暮らしではありません。 会社のオフィスは、立ち上げた当時は存在せず、全メンバーが在宅勤務でしたが、数年後に
AndroidアプリケーションのSSL通信をプロキシで解析する(1)
0x00. はじめに Androidアプリケーションの解析の際に、それがどのようなSSL通信を行っているかが重要となる場面がある。そのようなとき、Doormanのようなローカルプロキシでその通信をフックすることができれば目的が達成できる。 しかし通常の（PC上の）ウェブブラウザのSSL通信と同じように、Androidにも元々「信頼できるもの」として扱われるルート証明書群がインストールされており、これらの証明書を元にSSL通信が実施されてしまう。ただ単にローカルプロキシでSSL通信をフックしようとしても、当然「偽物の証明書である」としてエラーとなってしまうため、プロキシでのフックを実施するためには少し工夫が必要となる。いくつかの方法が考えられるが、このエントリではまず筆者が一番はじめに試した方法を紹介する。 0x01. 対象 まず、今回はURLConnectionクラスを使ったSSLのアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
