この投稿は AWS Advent Calendar 2014 の 22日目の記事です。 RDS で MySQL を運用中に、想定外の CPU スパイクに悩まされたことがありましたので纏めておきます。 まずは、CloudWatch のグラフを見てみましょう。 所々で CPU スパイクが発生しているのがわかるかと思います。一見すると法則性がないようにも見えます。一般的には CPU リソースを消費する要因としては、アクセス過多やバッチ処理などで負荷をかけたケースが殆どです。しかし、今回のケースはユーザー側では何も負荷をかけておらず、RDS へのアクセスがゼロのサーバーでも同様の CPU スパイクが発生することがわかりました。 CPU スパイクの原因は？ では、CPU スパイクの原因は何だったのでしょう？その後の調査で「RDS の定期メンテナンスジョブ」が原因であることがわかりました。 以下、メン

2015/12/18追記 マネージドNATが出たので、わざわざNATを建てずにこちらをまず検討すると良いと思う。 Amazon Web Services ブログ: 【新機能】マネージドNATゲートウェイが利用可能に ーーー t2.microでNATインスタンスを建てようとするも、NAT用AMIは PVしかない(2014年7月11日時点)という理由で諦めてる人向けのメモ。 (NATインスタンスの建て方自体は、このページ末尾のSlideshareを参考に) 基本的にやることはPVもHVMも変わらず、 ip_forward有効にしているLinuxを起動 EC2の設定で src/dst checkをdisabledにしておく routing tableを適切に設定しておく これさえキチンとしていれば、たいていのLinuxで( Vyatta等を含む)動作するので、HVMかPVかはそもそも関係ない。(

AWS Security Blog A New and Standardized Way to Manage Credentials in the AWS SDKs One of the advantages of using the AWS SDKs for programmatic access to AWS is that the SDKs handle the task of signing requests. All you have to do is provide AWS credentials (access key id and secret access key), and when you invoke a method that makes a call to AWS, the SDK translates the method call into a signed

ファイルやディレクトリに対する予期せぬ操作や改ざんを防ぐために、特定のファイルやディレクトリ配下のファイルに対する更新（追加/変更/削除）操作を検知する方法は、一般的にとられます。 今回はEC2 Linuxのファイル・ディレクトリ監視をCloudWatchとinotifywaitを使って実現してみます。 inotify-toolsのインストール inotifywaitとは、inotify-toolsに含まれる、ファイルに対する変更を検知するツールです。 inotify-toolsは下記コマンドでインストールできます。 inotify-toolsはAmazonLinuxの標準のyumリポジトリには登録されていません。 AmazonLinuxにもEPELのyumリポジトリが登録されていますが、デフォルトでenabled=0となっているので明示的にenablerepoする必要があります。 yum

20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto S...Amazon Web Services Japan

$ date 2014年 5月30日 金曜日 20時56分02秒 JST $ echo 'select now()' | mysql -h mysql.foobar.ap-northeast-1.rds.amazonaws.com -u admin -p Enter password: now() 2014-05-30 11:56:20 アンチパターン init_connect に "SET SESSION time_zone = 'Asia/Tokyo';"と書く →フェイルオーバー時にハマる (rdsadminユーザなどではTimezoneがUTCでないとダメ) ストアドプロシージャを入れて init_connect から呼ぶ 例)

はじめに こんにちは植木和樹です。 このエントリは『アドベントカレンダー2013：AWS CloudFormationビッグバンテンプレート』14日目の内容となります。今回は『毎日定時刻にEC2スナップショットを自動取得する格安ソリューション』を一発構築してみたいと思います。 先日13日目は都元さんのGitBucket編でした。 「ソンナコトモアロウカト」について EC2インスタンスを利用する際は通常ローカルディスクにEBSを用いるかと思います。EBS自体はAWS内部で冗長化されておりデータ消失の可能性が極低いです。とはいえEBS破損の可能性はゼロではないですし、オペミスによるファイル削除の可能性もあり日々のスナップショット取得は行っておきたいものです。 日々定時刻にスナップショットを取得するAPIを呼び出せばいいだけなのですが、それだけのためにEC2インスタンスを常時稼働させるのはコスト

はじめに AWSのEC2にはSecurityGroupと呼ばれるファイアウォールがあります。"指定したIPアドレスから、特定のポートのみアクセスが可能"といった指定をすることでセキュリティを上げることができます。 ただ、会社のような固定IPを持った場所からのアクセスではよいのですが、モバイル機器などを用いる場合は毎回IPアドレスを指定するというのは非現実的です。というわけで、スクリプトをつくって省力化してみました。 sshをする前にSecurityGroupに自分の利用しているIPによるSSHを許可して、ssh終了後に追加したルールを削除するというスクリプトです VPNを使うのが本筋だとはおもいますが、いつもできるというわけではないので、役に立つ場合もあるかもしれません。 スクリプトの概要と実行結果 myssh.sh というシェルスクリプトを作ってみました。短かいコードですのでまずはコード

kitchen-dockerでEC2の料金をかけず、高速にAmazon LinuxでのCookbookのテストを行う方法 2014.04.28 追記： ライセンスについてのご質問をいただいたので追記しました。 最近、Kitchen-dockerでCookbookのテストを流すようになり、 捗ってはいたのですが、 仕事ではCentOSとAmazon Linuxの両方を使うことがあり、 お互いRHEL互換で大体同じで通るとはいえ、 ちゃんと両方でテストしないといけないよな〜と思っていました。 でも、Amazon Linuxを使おうと思うと、 kitchen-ec2とかvagrant-awsとかで立ち上げる感じになって、 やっぱり仮想マシンの立ち上げが遅いんですよね。 あと、課金を気にしなきゃいけないのが一番やりにくい。 とりあえず、今やってるCookbookの充実＆リファクタリングは早く終わら

Docker Meetup Tokyo #2でLTしてきた:「Docker+serverspecで作るconfigspec CI」 #dockerjp はじめに 2014年4月11日(金)に開催されたDocker Meetup Tokyo #2で、「Docker + serverspecで作る configspec CI」というタイトルでLTしてきました。 この内容について、少し詳細に落とし込んだのがこの記事です。拙いところも改善するべきところもいっぱいあるんですが、とりあえず動いたよ、というところで。 イベント中のtweetはTogetterにまとめました。 Docker Meetup Tokyo #2 #dockerjp - Togetterまとめ やりたいこと 結果としてやりたいこと、出来上がるものがこちらの図になります。 configspecとserverspecをRakefile

Amazon Linux AMI 2014.03 出ました！ Dockerが標準レポジトリに入ったことですし、せっかくなのでAmazon Linux AMIのbaseイメージを作ってみた。 準備 アップロードの時にネットワーク的に近くて良さそうなので、us-east-1リージョンで作業を行います。 AMI は amzn-ami-minimal-pv-2014.03.0.x86_64-ebs (ami-5573643c) を使います。 Management ConsoleでもAWS CLIでもよいですが、blockdevice mappingの指定が楽なので旧API Toolsで起動。 $ ec2-run-instances --region us-east-1 -k KEYPAIR -g GROUP -b /dev/sdf=snap-bb9e9f63:10:true ami-5573643

ども、大瀧です。 前回のブログエントリーで、「EC2のswap領域は起動時にインスタンスストア上に作るといいよ！ただしインスタンスストア既定のファイルシステムはオススメできなくて、その辺ごにょごにょ実装してね☆」という、微妙にイケてないベストプラクティスを提言してみました。「なんだよ、簡単にできるんじゃないのかよっ！」とご立腹の方もいるかもしれません。アンサーブログとまでは言いませんが、簡単にその辺りの機能を実装するRPMパッケージ ec2-swap を作ってみたので、使い方と仕組みをご紹介します。 動作確認環境 Amazon Linux AMI 2013.09.2 - ami-0d13700c (64-bit) ロードマップとしては、CentOSとRHEL AMIを近日中に動作確認、aptリポジトリの作り方がわかればUbuntu(debパッケージ)向けに対応していきたいです。(小声で)

メール配信サービスを調べていたら、調子に乗って 月間のメール配信数ごとの価格比較グラフ ができあがりました。 http://atskimura.github.io/compare/cloud-mail.html 多すぎ！w 以下で細かく見て行きましょう。 なお、ここで言うメール配信サービスはAmazon SESやSendGridなど、アプリから通知メールを大量配信するときなどに使うサービスです。 対象サービス 対象にしたサービスは以下の13個。相変わらずいっぱいある。 Amazon SES SendGrid、SendGrid（日本） Mailgun Postmark Mailjet Mandrill LeaderSend SocketLabs Elastic Email turboSMTP PostageApp Critsend ニフティクラウド ESS MailChimpなどのマーケティ

よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB

This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

CloudWatchの値をZabbix側でも見られるようにしたので、その手順を共有します。 CloudWatchの値をZabbixで取りたい理由 Zabbixでは最初から非常に多くの項目を監視できるのですが、AWS等のクラウドを利用していると、必要だけど監視できない項目が出てきます。RDSやELB等のフルマネッジドサービスのリソース状況はもちろんのこと、EC2のCPU使用率といった一見Zabbixで監視できそうなリソースも、実は正確な値は取れていません。 一方、CloudWatchはEC2内部の情報、例えばロードアベレージやプロセスの監視はできません。また、データの保持期間が14日間なので古い情報は見られません。 そこで、CloudWatchの情報をZabbixに貯めるようにすれば、、両方を一元的に管理できるし、情報の保持期間も好きなように設定できるようになります。 Zabbixの外部チェ