Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で ■AWSのELBとApacheを使う際の注意点 ・Timeoutは120以上が推奨 ・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。 という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！) 根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。 ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCP
相澤さんインタビュー: 開発者を応援するためにHerokuに飛び込んだ [[JAWS DAYS 2013 Araki room]] #jawsug
相澤さんインタビュー: 開発者を応援するためにHerokuに飛び込んだ [[JAWS DAYS 2013 Araki room]] #jawsug 2013年春、東京ビッグサイトへ集結せよ！という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group）が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。 荒木が進行した「荒木の部屋・AWSサポート出張所（松井の部屋）」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。 Herokuの相澤さん(@ayumin)の登場です（Youtube） 先ず、これを読んだ人は http
AWSに関する書評：ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド
クラウドアンチパターン研究家の荒木です。ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド (日経BPムック)を購入したので、早速読んでみた。 136頁から141頁迄の間に、「【第8章】 クラウドアンチパターン」のAmazon Web Servicesの節があった。この頁の出典は2012年11月の日経SYSTEMSのものだった。 S3-backedのEC2の場合にデータが消えることがあるという記事に関しては、EBSから起動するEC2を選ぶ「EBS-backed」のEC2がデフォルトになってから随分経つのに、いったんついたイメージは消えないのだなという感想。記事中ではEBSのことも触れてはあるのだが、EBSから起動できるEC2についてはあえて触れていないように見える。 このように記事が古いだけなのか、「書きやすい」ので意図して残したのかはわからない。率直な私の感想としては、
ログ解析で楽をする話 #qpstudy でしてきました。
ログ解析というのはインフラエンジニアの基礎の基礎です。アプリケーションが定まればそれなりのログ解析ツールは存在します。Debianのstableですら数十のツールがあります。 とはいえ、実際のログというのは往々にしてアプリケーション毎に全然ちがっているのでツールは役に立ちません。結果としてgrepを駆使したり、はたまたRDBに突っ込んだりして試行錯誤することになります。 見事に解析できたとしても、それを可視化することを考えると楽できることを考えておきたいわけです。 そこで役に立つのはログ解析SaaS．Sumologic, SplunkStorm, Logglyなどけっこうありますが、qpstudyではSumoLogicを紹介してみました。GUIでログを横断的に絞り込めますし、その処理構文はいつでも繰り返すことのできるすぐれものです。 無料で使えるサイズでかなりのことができますので、ちょっと
インフラエンジニアのキャリアとして大手ベンダーから始めるのも悪くない | debiancdn
私は、AWSで提供しているサービスは間違いなくインフラの中核技術であること、今後もAWSはインフラの中核技術を出し続けるであろうことを確信しています。AWSというのを「クラウド事業者」「大規模事業者」などなどに置き換えてもいいでしょう。しかし、それらの今うまくいっているプレイヤーに「乗っかる」戦略もそんなに悪いものではないと思っています。 Open database life: インフラエンジニアのキャリアとクラウドについて ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 Linuxなり
DevOps Day Tokyo 2012に参加してきた(昨日の話)ので報告と雑感。
昨日DevOps Day (sじゃない)のイベントがセルリアンタワーのGMOであったので参加してきた。 今回は正直誰が何をしゃべるのかもわからなかったので速攻で申しこみだけをしておいた。そうしたら、opscodeもenTRUSTもいるという俺得なイベントでした。積極的に質問もしたら、いろいろ出てきたのがサイコーだった。そんなわけで、いろんな話もできたし、最後に一本締めのときに前に出ることにもなったり、とても楽しい一日でした。講演者の方々、主催、スポンサー、会場のGMOの方々ありがとうございました。 全体の雰囲気は、http://togetter.com/li/310514、隣で取材してた新野さんのpublickeyに出る気がするのでそちらを参照。 以下は自分が体験したこと。 まず、opscodeのGeorge Moberlyさんから、 次のchefバージョンではDry Runがサポートされ
NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較など。
NHNテクノロジーカンファレンスにいってきた。 DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。 実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。 このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。 サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。 RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
