多段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に流す実装となって
シンガポールにAWSがやってきたのでレイテンシを計測してみた - stanaka's blog
シンガポールにAWSがやってきました。Amazon EC2、S3だけではなく、Amazon RDSなど、VPCを除いた、ほぼフルセットとなっているようです。 We've just opened up an AWS Region in Singapore, with two Availability Zones. The new region supports Amazon EC2 (including Elastic IP Addresses, Amazon CloudWatch, Elastic Block Storage, Elastic Load Balancing, and Auto Scaling), Amazon S3, Amazon SimpleDB, the Amazon Relational Database Service, the Amazon Simple Queu
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
はてなのインフラ、いまむかし @ サーバ/インフラ Tech Meeting - stanaka's blog
先週の金曜にサーバ/インフラ Tech Meetingで「はてなのインフラ、いまむかし」という発表をさせていただきました。先日発売された「サーバ/インフラを支える技術」の新刊記念のイベントです。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行本（ソフトカバー）購入: 132人 クリック: 2,246回この商品を含むブログ (283件) を見る 発表内容は、OSC 2008 Kansai in Kyotoでid:naoyaが発表したはてなのインフラの歴史の抜粋に加えて、今後、発展させようしている方向性について話させていただきました。ちょっと30
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
