cdn.debian.netの中身と開発計画を大統一Debian勉強会でしゃべってきたcdn.debian.netの中身をきちんと説明したことがなかったのでやってみたのだが、５分では短かすぎた。 多くの人に興味をもってもらえそうなことを前に持ってきたのはいい（たぶん） 開発協力者に対してちゃんと説明しなければならない後半が飛ばしまくりになった。 今日はcdn.debian.netのRuby2.0対応をしていて微妙に時間をつかった。しかも途中。。 via http://arakinotes.blogspot.com/2013/06/cdndebiannetdebian.html
EC2およびS3の価格をプログラマブルで計算したい人はJSONをたたこう
AWS の月額費用をシミュレーションする AWS Simple Monthly Calculator は初登場が2007年の6月(たしかそのあたり）。かれこれ6年近くになる。 当初はこんな超すっきりページだったらしい。（白状すると、このバージョンは使ったことがない。2008年夏のUpdateは使った記憶がある） AWSの料金計算API欲しい…。SDKから叩ける奴…。そしてSIMPLE MONTHLY CALCULATORよりも詳細な奴…。 #jawsug — 都元ダイスケさん (@daisuke_m) 2013年5月10日 ということなので情報提供。EC2およびS3の価格は次のURLから取得可能です。 http://aws.amazon.com/ec2/pricing/pricing-on-demand-instances.json http://aws.amazon.com/ec2/pr
ログ解析で楽をする話 #qpstudy でしてきました。
ログ解析というのはインフラエンジニアの基礎の基礎です。アプリケーションが定まればそれなりのログ解析ツールは存在します。Debianのstableですら数十のツールがあります。 とはいえ、実際のログというのは往々にしてアプリケーション毎に全然ちがっているのでツールは役に立ちません。結果としてgrepを駆使したり、はたまたRDBに突っ込んだりして試行錯誤することになります。 見事に解析できたとしても、それを可視化することを考えると楽できることを考えておきたいわけです。 そこで役に立つのはログ解析SaaS．Sumologic, SplunkStorm, Logglyなどけっこうありますが、qpstudyではSumoLogicを紹介してみました。GUIでログを横断的に絞り込めますし、その処理構文はいつでも繰り返すことのできるすぐれものです。 無料で使えるサイズでかなりのことができますので、ちょっと
安藤さんインタビュー：Publicフレームワーク最強を目指すEngineYard [[JAWS DAYS 2013 Araki room]] #jawsug
安藤さんインタビュー：Publicフレームワーク最強を目指すEngineYard [[JAWS DAYS 2013 Araki room]] #jawsug 2013年春、東京ビッグサイトへ集結せよ！という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group）が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。 荒木が進行した「荒木の部屋・AWSサポート出張所（松井の部屋）」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。 Engine Yardで活躍中の安藤さんには1日目のLTの内容をうけて、インタビューさせてい
![安藤さんインタビュー：Publicフレームワーク最強を目指すEngineYard [[JAWS DAYS 2013 Araki room]] #jawsug](https://cdn-ak-scissors.b.st-hatena.com/image/square/96a00c91956670bcd67481fc4ababe645c46dfbd/height=288;version=1;width=512/http%3A%2F%2Fdonrails-web.s3.amazonaws.com%2Fimage-bucket%2F2013%2Fjawsdays%2Fando-panda.png)
インフラエンジニアのキャリアとして大手ベンダーから始めるのも悪くない | debiancdn
私は、AWSで提供しているサービスは間違いなくインフラの中核技術であること、今後もAWSはインフラの中核技術を出し続けるであろうことを確信しています。AWSというのを「クラウド事業者」「大規模事業者」などなどに置き換えてもいいでしょう。しかし、それらの今うまくいっているプレイヤーに「乗っかる」戦略もそんなに悪いものではないと思っています。 Open database life: インフラエンジニアのキャリアとクラウドについて ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 Linuxなり
高橋さんインタビュー：SNS+SQS+Nodeで簡単にユーザーサポートシステム [[JAWS DAYS 2013 Araki room]] #jawsug
高橋さんインタビュー：SNS+SQS+Nodeで簡単にユーザーサポートシステム [[JAWS DAYS 2013 Araki room]] #jawsug 2013年春、東京ビッグサイトへ集結せよ！という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group）が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。 荒木が進行した「荒木の部屋・AWSサポート出張所（松井の部屋）」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。 SNS+SQS+Nodeで簡単にユーザーサポートシステムができた(Youtube)という話で昨
jhottaさんインタビュー：「未だ試していないの？Chef11 Server!」 [[JAWS DAYS 2013 Araki room]] #jawsug
jhottaさんインタビュー：「未だ試していないの？Chef11 Server!」 [[JAWS DAYS 2013 Araki room]] #jawsug 2013年春、東京ビッグサイトへ集結せよ！という掛け声で、3月の15日、16日の二日間アマゾンウェブサービスのユーザグループであるJAWS-US (Japan AWS User Group）が全国から一同に会してユーザカンファレンスを行いました。当日のタイムスケジュール、資料、動画はこちらから参照できます。 荒木が進行した「荒木の部屋・AWSサポート出張所（松井の部屋）」についてはUstream中継の記録がいつでもご覧いただけます。本記事はそこでの会話内容、プレゼンテーション内容を元にしています。一連の記事はこちらで順次追加公開していきます。 @jhottaさんは初期からJAWSUGに参加されているメンバーです。jhottaさんのY
cdn.debian.net と ftp.jp.debian.org の動作に問題があればgithubにおねがいします。
cdn.debian.net と ftp.jp.debian.org の動作に問題があればgithubにおねがいします。 Debianにおけるパッケージ流通はaptが基本的なものになっている。いまどき完全なスタンドアローンで動作しているような例もすくないので、なにかしらaptの御世話になっていることは多いかと思う。 昔のaptの実装ではhttp redirectができないので、http redirectに頼らない誘導方法になっている（現在のaptの実装ではhttp redirectができるので、http.debian.netというサービスが誕生している）。 check_serverの実装自体はRails3.2です。 動作チェック、文句、要望について チェックサーバの動作は http://cdncheck1.araki.net/view/index で確認できます。 https://gith
ruby1.9.3 macosx でrailsが動かない件が解決した
結論を言えば、ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-darwin11.4.2]を使うのであれば、 brew install libksba しとけってこと。 経緯としては、 $ which rails /usr/local/Cellar/ruby/1.9.3-p362/bin/rails とでるのにもかかかわらず、 $ rails Rails is not currently installed on this system. To get the latest version, simply type: $ sudo gem install rails You can then rerun your "rails" command. となって堂々巡りになってしまった。 何度もgem install railsをバージョン変え
VPCのメタパターンもしくは怠惰な私のVPC導入。
皆様、昨日の松井さんの男気あふれる記事に度肝を抜かれた荒木でございます。毎度のことながら彼の軌跡は奇跡として語り継がれるといって間違いないでしょう。 さて、VPC環境構築のメタパターンと予告しました。実際のところCloudformationの出番は無限です。その中でも最も強力なのは、ある状態を保存再現する機能です。VPCのように面倒な環境構築に有効です。 時間のない人のために結論を。 CloudFormationはある時点の状態再現に有効です。 VPCに関しては再現を自動化するのは諦めて、（時としてつまらない）設計を再現するためにCloudFormationを使いましょう。 実はVPCIDを使えばClassicな環境からの移行は簡単！ というわけで、CloudFormationこそがVPC導入のポイントかもしれません。 これから述べる内容は ELB アプリケーションサーバ データベース(R
TCP window controlが肝な話
クラウドはクラウドというくらいでネットワークの先に資源があり、そこにたどり着かない限りなんにもならない。そして、世の中遠くのネットワーク資源を使うための工夫は数限りなくある。 B2B的な、通信相手が固定されているなら、AsperaでもSteelheadでもSkeedでも好きなものを使えばいいのだが、マスが相手となるとそうは行かない。TCPを使うしか事実上ない。もっというとHTTP＋TCP（よくてHTTPS)をどうするかということに注力するしかない。 で、基礎知識としてはTCP Windowコントロールとなる。自分のブログで “TCP window” で検索→https://debiancdn.wordpress.com/?s=TCP+window すると、けっこう頻繁にTCP Windowコントロールのことを書いているな。。 とはいえパイプ計算機について書いたことがなかったようだ。 SWI
査読のミサワ
7月16日の日記。査読が大変だと妻に言うと、頼まれるのは誉れなことなんだから、感謝しなさい、と言われてそれもそうだなと思いました。→「査読をするのも研究のうち」 d.hatena.ne.jp/mamoruk/201207… — Mamoru Komachiさん (@mamoruk) 7月 24, 2012 ちょっと触発されたので、まったく抜けたことを書いてみる。 ある程度その世界での経験がある人なら、論文でも、原稿でも、あるいは人のblogでも査読をする機会の一度や二度はあるだろう。 だいたい論文の査読だとこう思って読むことは2割くらいだろうか。 そして、論文の場合は査読としては読むだけでは当然おわらず、わりとちゃんとした返事を書かねばならない。 もうちょっとで採録! というのならばいいのだが、そうでないときは..
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
NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較など。
NHNテクノロジーカンファレンスにいってきた。 DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。 実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。 このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。 サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。 RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなイン
コード書けるインフラエンジニアの深刻な不足問題
インフラエンジニアを厳密に定義しないであえて使うことをお許しください。 だいたいは、ゼロスタートの山崎さんの記事を見てほしい。 巷で聞かれる、「インフラエンジニアの深刻な不足問題」は、実は「コード書けるインフラエンジニアの深刻な不足問題」であり、それは「コード書けるインフラエンジニアへの深刻な給与不足問題」なのではないかと思うのです。 インフラエンジニアに15年前にはいった人(私は大学卒業が15年前なので感覚で語れるのはこのころから)は特にインフラエンジニアなどとは呼称されていなかったはずです。オープン系サーバ屋、オープン系ネットワーク屋、汎用機のプログラマ、IPのネットワーク、ATM、sonet、INSのエンジニアなどのように分類されていたように記憶しています。もちろん複数の分野を持つ人、持たざるをえなかった人が時代を推進していたことは事実です。しかし、そのように区分されて業界にはいって
PVでサーバを見積ることはおすすめしません
「私のサービスは毎月1億PVくらいになりそうなんですけど、どのインスタンスがいいですか?」 こんな質問をときたま受ける。マジレスすると、 1ページあたりの転送量がわからん どれだけのキャッシュをブラウザに効かせるのかわからん そもそもそのページが動的に生成されるとして、その重さがわからん などなどの理由で、ずばっと答えられないので、相手をガッカリさせることがある。 責任のある答えは「試しに作って測定してください。測定して、足りなければ増やせばいいので」というのが私の典型的な回答になる。 もちろん、超ざっくりでいいなら、こんな例えをしてみる。 1ページあたり1MB、ブラウザキャッシュは考慮しないとして、30PV/sec とすると、30MByte/sec == 240Mbit/sec なので余裕もったサーバなら1台あたりはこんなもんじゃないかと。AWSならlargeインスタンスでならなんとかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
picasawebでなぜか写真埋め込みのリンクが消えた
Debian大統一勉強会いってきた
「ウチの社員は外にでるときは全員CTOクラスになれるのをめざしてますから」 « debiancdn