Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ
10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか
Webエンジニアが目を通しておきたいインフラの基本の本 - たごもりすメモ
「Webエンジニアが知っておきたいインフラの基本」を著者の馬場さんから献本いただきました*1。ありがとうございます。 ITインフラの設計やら構築やら運用やらに関わりながら仕事をするようになってそれなりの年数になった。日頃おろそかにしている部分もあれば専門だと思って自信をもってやれることもある。その中でたまに思うのは、何が当たり前で何は当たり前ではないのか、ということがよくわからなくなってきたなあ、ということだ。 障害対応時の心構えは？ そもそもシステムメンテナンスにおける心構えとは？ Webアプリケーション基盤の設計方法は？ 非機能要件にはどのようなものがあるか？ パフォーマンスとは何を指すのか？ どんなサーバにも入っているツールで調べものをするときの鉄板は？ サーバのパフォーマンスを示すグラフの見方は？ どのような兆候が出ていたら注意しなければならないのか？ どの数字にどういった意味があ
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
tagomorisとDMM.comのはなし - たごもりすメモ
前にこんなblogエントリを書いた。 dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ このエントリ、Cassandra Casualという勉強会でCassandraのようなそうでないような話を聞きながら、しかもビール2本飲んだ状態で書いたものだった。書いてさっさと公開して放っておいた*1ところ、だいぶ経ってはてブがやたらとついていることにびっくりしたものだった。 正直に言おう。対象はなんでもよかったんだ。世間に知られている大規模インターネットサービスを運営していて、会社としての・中の人としての雑誌記事やイベント登壇やblogエントリがあまり見られない企業であれば。DMMでなくても、たとえばFC2でも楽天でもNTT docomoでもY!Jでもドワンゴでも。 もちろんどんな会社の人でも行くべきところに行けば中の人がいるのは知っているけれども、そういう話じゃない。単に
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
#java_ja で例外とロギングについて勉強会をやるというのでいってきた＆飛び込みLTやった＆運用の視点から見たアプリケーションのログについて - たごもりすメモ
LOG.debug("nice catch!") - connpass 2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja - Togetterまとめ blogエントリを書くまでがjava-jaだと聞いたのでとりあえず書く。超まとまってません。各スピーカーの話の内容については他の人のblogに(たぶん)書いてあるのでそっちを見るとかTogetterを眺めるとかすればよいのではないでしょうか。 主催のみなさま、および会場提供のGREEさま、ありがとうございました。そういえばGREEでの勉強会って初めて参加した気がする。六本木ヒルズの入館、だいぶ簡単になりましたね。 いってきた どっちかというとアプリケーションのコード書く人が多かったんですかね。という感じで、アプリケーションコードからいかにして例外を投げるか、それをどのよ
尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
サラリーマン人生における希望と絶望 - たごもりすメモ
自分のささやかなサラリーマン人生において、大きい会社(の一部)も小さい会社も見てきたけれど、そこで気付いたことがあって、そんなもやもやが堆積してきたのでここに吐き出す。たぶんまとまらない。 サラリーマンには2種類いる。 会社を肯定する奴と文句ばかり言う奴、ではない。会社の文句を言う一方、同じ口で会社を肯定することも言う奴、と、会社のことを肯定も否定もしない奴だ。*1 自分の所属する会社に対して不平を言う人はけっこういる。取締役会の決めることや人事異動や予算配分やプレスリリースにしじゅう文句を抱えていて、お昼休みや飲み会やタバコ部屋であーだこーだいう話をする人はたぶんどこにでもいる*2。 曰く、なんで会社が利益を出せているかが分からないくらいだ、会社がなんで存続できているかが不思議だ、あの上司はなんにもわかってない、今度のアレは失敗するに決まってる、あそこのアレがいつまでも改善されなくてうん
いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日本語で何を言われてもぶっちゃけ
xargs を使ってカジュアルに並列処理 - たごもりすメモ
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ
仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで「RAID-1+0にしないとRAID-6とか怖くて使えませんよ！」というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。 1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて「いやあデータの安全性を考えるとRAID-1+0」とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ry まあそんな感じで。ちなみに正しくない運
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
