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

ログ解析というのはインフラエンジニアの基礎の基礎です。アプリケーションが定まればそれなりのログ解析ツールは存在します。Debianのstableですら数十のツールがあります。 とはいえ、実際のログというのは往々にしてアプリケーション毎に全然ちがっているのでツールは役に立ちません。結果としてgrepを駆使したり、はたまたRDBに突っ込んだりして試行錯誤することになります。 見事に解析できたとしても、それを可視化することを考えると楽できることを考えておきたいわけです。 そこで役に立つのはログ解析SaaS．Sumologic, SplunkStorm, Logglyなどけっこうありますが、qpstudyではSumoLogicを紹介してみました。GUIでログを横断的に絞り込めますし、その処理構文はいつでも繰り返すことのできるすぐれものです。 無料で使えるサイズでかなりのことができますので、ちょっと

私は、AWSで提供しているサービスは間違いなくインフラの中核技術であること、今後もAWSはインフラの中核技術を出し続けるであろうことを確信しています。AWSというのを「クラウド事業者」「大規模事業者」などなどに置き換えてもいいでしょう。しかし、それらの今うまくいっているプレイヤーに「乗っかる」戦略もそんなに悪いものではないと思っています。 Open database life: インフラエンジニアのキャリアとクラウドについて ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は本家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 Linuxなり

LinuxのDistributionは結果で判断されるが、その結果までの道を示すと免責されればいいのに。 先日、Cloudpackさんでイベントがあったのでしゃべってきた。 Cloudpackのsuz_labさんは、随分昔からCentOSベースでカスタマイズしたAMIを作成している。 彼はその取組というかロードマップを話をした。 自分はその話を聞きながら、コメントを付ける形で発表するとおもしろいかとおもって話をしてきました。 正直いって、LinuxのDistributionを真面目にやるのは大変すぎる。 入ってるあらゆるプログラムの脆弱性に対応しないといけないし、どうかするとプログラム自体の使い方がわからないとい言ってくるような人も相手にする状況にも陥る。 自分のDistributionはどんなもので、どのように作ることができるかを宣言していれば何かがあったときにでも「免責になる」というよ

皆様、昨日の松井さんの男気あふれる記事に度肝を抜かれた荒木でございます。毎度のことながら彼の軌跡は奇跡として語り継がれるといって間違いないでしょう。 さて、VPC環境構築のメタパターンと予告しました。実際のところCloudformationの出番は無限です。その中でも最も強力なのは、ある状態を保存再現する機能です。VPCのように面倒な環境構築に有効です。 時間のない人のために結論を。 CloudFormationはある時点の状態再現に有効です。 VPCに関しては再現を自動化するのは諦めて、（時としてつまらない）設計を再現するためにCloudFormationを使いましょう。 実はVPCIDを使えばClassicな環境からの移行は簡単！ というわけで、CloudFormationこそがVPC導入のポイントかもしれません。 これから述べる内容は ELB アプリケーションサーバ データベース(R

ついに出た、やっと出た、AWSの長期保存用ストレージ。 http://aws.amazon.com/glacier/ 【AWS発表】 Glacier – 1GBあたり月額約1円で利用可能なアーカイブストレージが登場 – Amazon Web Services ブログ Glacier – 1GBあたり月額約1円で利用可能なアーカイブストレージが登場 本日AWSはまた新たなサービスである、Glacierをロウンチしました！ ってことで、AWS公式ブログにも出ているように、安くて保存に向いている。 例によって、AWSにアップロードするトラフィックは無料なので、保存したままにしておくのであれば、ストレージコストだけで済む。 ダウンロードが高いというのであれば、専用線でむすぶ http://aws.amazon.com/jp/directconnect/ がある。 いろいろと周辺ツールが揃ってくるま

VPC上でサービスを作成することは、Eコマースサイトにおいて必ずしも必要なことではない。その一方で、VPCでなければ満たせない各種の基準を満たすため、各種のサービスを使うために、VPC上にサービスを作成することはおおきなメリット。 「基準を満たすため」の典型的な例は、国際ペイメント業者5社が共同で作成したクレジット業界におけるグローバスセキュリティ基準であるPCIDSS(Payment Card Industry Data Security Standard)の取得。PCIDSSは情報セキュリティに対する具体的な実装や施策を要求しており、クレジットカード情報と全く関係ない企業や組織ですらPCIDSSを基準とした情報安全対策を求められることが増えています。 その中には、”Build and maintain a secure network” なる条項があり、VPCはinboundだけではな

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

【AWS発表】Amazon RDS MySQL を月26ドルで! マイクロDBインスタンスが利用可能に! ということで、安くRDSを使うことができる。ただし、マイクロインスタンスなのでどうしようもなく遅い。耐えられないくらい正直遅い。 が、それを逆手にとった活用法がある。 それはスロークエリの検出。

1以上のintegerですね。RT @hiroohi: あれ？RDS(mysql)のParameterGroupって、long_query_timeは1秒以上しか設定できない？ #jawsug — ARAKI Yasuhiroさん (@ar1) 6月 13, 2012 いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。 そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。 漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全

散々Amazon RDS for MySQLなるMySQLサービスを売っているのだが、それでもMySQL Enterprise Editionはすばらしい製品に見える。 違いをメモってみるか。ちなみにRDSはMySQL community edition. MySQL Enterprise Backup: これはRDSはバックアップの仕組み(snapshot)もあるしポイントインタイムリカバリもあるからいいか MySQL Enterprise Monitor: MySQL Query Analyzerいいなあ。RDSにないし。 MySQL Workbench: 管理ツールはまあRDSにはいらないのかもしれない。 MySQL Enterprise Security: LDAPやAD連携なんかはいいよね。RDSにもあっていいね。 MySQL Enterprise Scalability: スレ

Installing AWS Command Line Tools Using Ubuntu Packages というすばらしい記事が http://bit.ly/JTpa8f で読めるのでそれのインスパイアというか、ちょっと修正しただけ。 まずはAmazon EC2 API Toolsをいれる。Ubuntuな場合は上であげた http://bit.ly/JTpa8f あたりを読めばいいけど、なるべく汎用的に書いてみる。 まずはJDKのインストール． 適当なdirectoryをつくる。UNIX系なら、~/.aws おすすめ。 ec2-api-toolsやautoscaling、ELBのコマンドファイルなどは http://aws.amazon.com/code にあるので、とってきて展開して、シンボリックリンクをつくる。まあ、やたら種類があるので全部いれる人は極めて稀だと思う。自分だとこん

今月の雑誌FUJITSUは京特集じゃないかってことで見ることをおすすめする http://jp.fujitsu.com/about/magazine/ 中でもおもしろいのはhttp://img.jp.fujitsu.com/downloads/jp/jmag/vol63-3/paper03.pdf にある京の建物の話。いままでおってなかっただけにおもしろい。一般のDCとちがって汎用で作られてないことと潤沢に予算があることがおもしろさのそもそもの源泉。

これもまた知られてないシリーズか。 ELBの扱えるTCP portは25,80, 443 or 1024 to 65535。 そして、違うportにアクセスしてもICMPでrefuseを通知したりはしない。 今は1024 upのものだけですね。HTTPやHTTPS等が特別扱い。。RT @matsukaz: そのうち何とかなるんですかねぇ (´；ω；｀)#jawsug RT @matsukaz: ELBで843ポートが使えないというワナ。まぢかー。 — ARAKI Yasuhiroさん (@ar1) 5月 24, 2012

VPCではプライベートIPアドレスだけで構成されているために、Publictなthe Internetに出ていけないインスタンスを置くことができる。 このようなインスタンスでも、NATインスタンスを使うことで、インターネットに出ていくようにすることができる。 Amazon VPCのNATインスタンスを作ってみる(Squid編) Amazon VPCのNATインスタンスを作ってみる(iptables編) Amazon VPCのNATインスタンスを作ってみる(環境準備編) 途中まで書いて気がついた。↑の記事がすばらしすぎることに。みんなこれを見るべき。 たまにNATインスタンスのパフォーマンスを気にする人がいるので、そのヒントを。 NATインスタンスはいくつでも作れるので、負荷分散 NATインスタンスを速いインスタンス(c1.xlargeとか)にすることも有効 Squidの透過proxyなどつ

NHNテクノロジーカンファレンスにいってきた。 DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。 実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。 このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。 サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。 RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなイン

sshの接続で楽するなら.ssh/configが良いよって教えてもらいました(*^_^*) @ar1さんありがとうございました。 — 小柴恵子(Netsket)さん (@netsket_koshiba) 5月 2, 2012 というわけで実はあまり知られてない方法なのかもしれないので、具体例を晒しとく。 Host *.ap-northeast-1.compute.amazonaws.com identityfile ~/.ssh/tokyo user ec2-user Host *.eu-west-1.compute.amazonaws.com identityfile ~/.ssh/dublin user ec2-user Host *.sa-east-1.compute.amazonaws.com identityfile ~/.ssh/saopaulo user ec2-user H

AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。 最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、 ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。 そもそも問題は、 ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。 ELBでTCPモードにした場合でも60秒でタイムアウトする。 の2点が原因です。そのため、2つの方法があります。 解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法 C ---------> ELB(HTTPモード) --> S ふつうにHTTPでアクセス。

たぶん http://techie-buzz.com/tech-news/u-s-veterans-amazon-wants-you.html をみるのがいい。 Amazon.com announced that it seeks to hire thousands of U.S. veterans for its fulfillment network. There are both full-time and temporary positions available. This is good news considering that G.I. Jobs magazine named Amazon as the “#1 Top Military Friendly Employer”.  Dave Clark, Vice President, North American Opera