タグ

ブックマーク / blog.stanaka.org (16)

  • 2014年のウェブシステムアーキテクチャ - stanaka's blog

    (Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWS格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWS格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerLXC (LinuX Conta

    2014年のウェブシステムアーキテクチャ - stanaka's blog
  • 多段fluentd + mongodb のハマリ所 - stanaka's blog

    fluentdを多段構成にして、mongodbに出力するところでハマったのでメモ。 上の構成のように、各サーバにfluentd + out_forwardを置き、集約するログサーバにfluentd + out_mongoでmongodbに出力している場合に、上段のfluentdでbuffer_chunk_limitを10mより大きい値にしていると、エラーになることがあります。 まず、out_mongoでbuffer_chunk_limitを10m以内にしないといけない理由は、fluentdからMongoDBへ連携する際の注意点 #fluentdを参考にしてください。 ここで多段構成の場合、上流の buffer_chunk_limitが大きいと上流から大きなサイズのデータの塊が流れてくることがあります。それを受けとったfluentdはそれをそのままoutput pluginに流す実装となって

    多段fluentd + mongodb のハマリ所 - stanaka's blog
  • fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog

    追記 2/22 毎回微妙に追記していますが、今回も追記です。最後にmongodbのinsert性能について80lines/secで厳しくなった、と書いてますが、環境か設定まわりがあやしいので訂正します。もうすこし検証してみようと思います。 → 検証して fluentd側の設定の問題であることが分かりました。詳しくは、http://blog.stanaka.org/entry/2013/02/22/171053 追記ここまで 最近は、fluentd + mongodb でログを蓄積していろいろ便利に使っているわけですが、数分に一回集計スクリプトを周したり、 GrowthForecast の画面をリロードしまくるのではなく、もっとリアルタイムで見たい! という欲求が募ってきたので、 node.js を使って実装してみました。( https://github.com/stanaka/realti

    fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog
  • Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog

    追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー

    Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog
  • Kindle Paperwhite向けに自炊pdfを最適化する - stanaka's blog

    id:halfrackがKindle Paperwhiteのタワーを作っていたので、Kindle Paperwhite向け自炊pdfの最適化をしてみました。 Kindle Paperwhite向けの自炊pdf最適化は、 余白を適切に削除すること 画像を最適なサイズである横658ドット x 縦905ドットにすること の2つが大事です。特に後者が重要で、デバイスごとに最適なサイズにすることでpixel by pixelで表示することができます。ちなみに、これまでのKindleでは横560ドット x 縦735ドットが最適でした*1。 調査には1ピクセルごとに線を入れたpdfを作成して行いました。このpdfでは、ページごとに画像サイズを1ピクセルずつ変えていて、最適な解像度ではない場合、綺麗に一様な模様にならず、すぐに分かります。これでちょっとずつ探りながら最適なサイズを探すわけです。地道ですね。

    Kindle Paperwhite向けに自炊pdfを最適化する - stanaka's blog
  • EC2上でMySQL Multi-masterフェイルオーバー - stanaka's blog

    EC2上では、仮想IPアドレスなどのIPレベルの機能が制限されているため、仮想IPアドレスを使用した冗長化は基的には使用できません。が、DNSを使用することで、VIPほどの精度は高くないもののMySQL Multi-master構成を構築することができました。 今回は、MySQL Multi-masterの切り替え用の支援ツールとして、Multi-Master Replication Manager for MySQLを使用します。このツールでは、MySQLの死活監視と仮想IPアドレスの切り替えを行ってくれます。 もちろん、EC2上では仮想IPアドレスは使えないので、そのままではうまく動作しません。ここで、このツールに含まれるns_agentを使用することで仮想IPアドレスではなく、DNSによる切り替えができるようになり、EC2上でMulti-masterを構築することができます。 今回

    EC2上でMySQL Multi-masterフェイルオーバー - stanaka's blog
  • KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog

    KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収

    KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
  • CPANモジュールをスクリプト一発で依存解決しつつrpm化する - とあるはてな社員の日記

    少し前にmizzyさんに そういえば、まっさらなサーバを30分で番投入できるようにする で stanaka さんが「CPANの依存関係を解析してrpm化する手製スクリプトで、CPANモジュールのrpm化が、ほぼ自動化されています」と書いてるんだけど、これって公開してくれないのかなー。 HowToRpmizeCpanModules - mizzy.org - Trac と突かれたので、githubで公開してみます。 http://github.com/stanaka/cpan-dependency/tree/master 突かれたついでにmizzyさんに軽く動作確認してもらったところ、それなりに動いているようです。また、はてなでは、このスクリプトを利用して、日々それなりの数のCPANモジュールのrpm化を行っていますので、だいたいうまく動くのではないかと思います。 CentOSやFedor

    CPANモジュールをスクリプト一発で依存解決しつつrpm化する - とあるはてな社員の日記
  • はてなでの仮想化技術の使い方@AMDセミナー - とあるはてな社員の日記

    先週、AMD主催のセミナーで「はてなでの仮想化技術の使い方」という発表をしてきました。 はてなでは、1年半ほど前から仮想化技術に取り込んでおり、現在では300台以上のサーバが仮想化されています。仮想化技術には、様々なメリットがありますが、はてなではサーバリソース利用率の向上と、システムの安定化の二つの利点を重視しています。サーバを仮想化していく際に、どのようなポリシーで一つの物理的なサーバに仮想化ホストを積み重ねているか、とか、実際どれぐらい効率を上げられているか、とか、あとAMDさんのセミナーなので、消費電力的にはOpteronが実測結果からは10〜20%程度効率がいい(負荷時にOpteron 1.82A, Xeon 2.17A)、というあたりの話をしてきました。 How to use Virtualization Technology in HatenaView more presen

    はてなでの仮想化技術の使い方@AMDセミナー - とあるはてな社員の日記
  • MySQL Conference 2008に行って来た - stanaka's blog

    今年もMySQL Conference 2008に行ってきました。社内向けの報告資料と雑多なメモですが、よろしければ参考にしてください。 *1 概要 MySQLがSunに買収されて始めてのConference 8セッション並列で、OSCONの規模にだいぶ近い MySQLが扱うトラフィック量・データ量がどんどん大きくなってきており、それにどう追従するか、という観点の話が多い 買収の話とか "MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に"というのは、かなりミスリーディングな記事 実体は一部のセキュリティ形の機能やnative storage engine-specific driverをMySQL Enterpriseとして出す、という話 Backup機能や、Falcon, Mariaといったストレージエンジンの開発では、Community ServerとE

    MySQL Conference 2008に行って来た - stanaka's blog
  • とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする

    すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定

    とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
    aki77
    aki77 2007/07/29
  • MySQL Conference & Expo 2007 - とあるはてな社員の日記

    一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di

    MySQL Conference & Expo 2007 - とあるはてな社員の日記
    aki77
    aki77 2007/04/28
    「Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッション」
  • keepalived de include - stanaka's blog

    keepalivedというサーバの信頼性を高めるためには、かかせないツールがあります。 去年の秋ぐらいにちょっと話題になったツールで、はてなでも便利に活用して、「もはや、keepalivedなしでは生きていけない」と言っても、過言ではないぐらいです。 ちなみに、keepalivedがどういうツールかというと、いわゆるお手軽ロードバランサで、バックエンドにウェブサーバやDBサーバが複数ある時に、死活監視をしつつ、適切にトラフィックを分散してくれます。さらに、keepalivedを2台構成にすると、VRRPというプロトコルで障害時に論理IPを付け替えたりもしてくれます。さらにさらに機能は豊富なのですが、とても説明しきれません。もっと、分かりやすい説明は、このあたりを探れば、じゃかじゃか出てくるので、そちらを参照してください。 今回の題は、keepalivedをヘビーに使い出すと、設定ファイル

    keepalived de include - stanaka's blog
  • mod_dosdetectorの反応への反応 - stanaka's blog

    先日(id:stanaka:20070204)、公開したmod_dosdetectorですが、ブクマ数が300users越えと予想以上の反響でした。その中で、いくつかFAQ的な反応があったので、それらに対する回答です。 mod_limitipconnでもできるんじゃないの? mod_limitipconnは、同時接続数を制限して、越えた場合は、接続拒否をするというモジュールです。mod_dosdetectorは、DoS判定したクライアントのみを対象とした制御が可能です。この手の定量的なアクセス制御モジュールは、これまでにいくつか開発されているのですが、ほとんどのモジュールが単純にアクセス拒否するだけ、というのも、mod_dosdetectorの開発動機の一つです。 パフォーマンスは? 確かに余分な処理が必要となっているため、CPU負荷は増えています。しかし、はてなのサーバ構成では、リバース

    mod_dosdetectorの反応への反応 - stanaka's blog
  • サーバにDoS耐性を付ける - stanaka's blog

    ウェブサービスでは、アクセスが集中して、サイトが落ちる、というのは、よくある話です。純粋に人気が出てアクセス集中するなら、サーバ管理側の責任と言われても、しかたないと思います。しかし、botやF5アタックによる突発的な集中アクセスで、落ちてしまう、というのは、運営側としても、あまり納得がいくものではありません。 そのような突発的なアクセスに対応するために、大量のアクセスをしてくるクライアントを検出し、優先度を落すか、アクセス禁止にする方法などがあります。 というわけで、Apacheモジュールでそれを検出するためのmod_dosdetectorを開発しました。(ちなみにコア部分の開発期間は、Apacheモジュールって、どう書くんだっけ、という状態から、3日でした。) mod_dosdetectorは、Apacheモジュールとして動作し、クライアントのIPアドレスごとにアクセス頻度を測定し、設

    サーバにDoS耐性を付ける - stanaka's blog
  • Adaptive Referer Remover 0.2.2 - stanaka's blog

    追記(07/01/29) v0.2.4にアップデートしました。 追記(06/05/05) v0.2.3にアップデートしました。 前書き かなり長いこと放置してましたが、ようやくアップデートしました。実は、今回のアップデート分の修正パッチは、ずいぶん前にもらっていて、絶賛放置中だったものでした。送ってくれた人、すいません〜。 ちなみに、Adaptive Referer Removerは、特定のサイト(イントラネット上のサイトとか)のURLがリファラで漏れるのを防止するFirefox拡張です。 ダウンロード インストール - refererremover.xpi 使い方 ステータスバーのアイコンがグレーの時は、リファラを送ります。カラーの時は、リファラをブロックします*1。 ステータスバーのアイコンをクリックすると設定画面が呼び出されます。正規表現を" "(半角スペース)で区切って、入力してく

    Adaptive Referer Remover 0.2.2 - stanaka's blog
  • 1