Lambdaの容量を監視しよう - @ijin
2016/1/14現在、AWS Lambdaにはなんとリージョン毎！にアップロードできるパッケージの合計サイズがたったの1.5GBという悲しい制限があります。特にlibraryを同包したり、versioningを使ったりしてCIをガンガン回してると、結構すぐこの上限に達してしまいがちです。そこで、Lambdaの総容量はAWSコンソール上には表示されるものの、トラッキングし辛いので監視する仕組みを作ってみました。 仕組み LambdaのScheduled Eventsを使って、ListFunctionsとListVersionsByFunction APIを叩いて、個別functionのCodeSizeをサマって、PutMetricDataでCloudWatchに投げて、Alarm設定してるだけ。 (*) 2016/1/26 追記：@marcy_teruiさんからのご指摘でVersionsの
Auto Scalingによる自動復旧（AWS Lambda+SNS編） - @ijin
先週のAWS Summit San Fransiscoにて、ついにLambdaがSNSに対応しました。 様々なサービスが発表された中、個人的にはこれが一番のヒットです！というのも、この機能によってAWS間のサービスがより連携しやすくなり、新しいリアクティブなアーキテクチャをどんどん実現できそうだからです。 というわけで、少し試してみました。 お題は去年12月に試したAutoScaling + Lambda。（当時はLambdaはまだこの機能がなかったのでSNS→SQSにてイベントをプロセスする仕組みを作りました。） SNS連携によって前回のこれが こうなります。（Lambdaのアイコンが出たので差し替えてます） うーん、シンプル！ 設定 前回とほぼ同様。 SNS作成
Auto Scalingによる自動復旧（AWS Lambda編） - @ijin
ちょうど1年程前に「非ELBなAutoscalingによる自動復旧」の再検証をしました。前回も復旧までのタイムラグが20分だったので、この1年で変わったかまた検証してみました。 (*) このエントリはAWS Advent Calendar 2014の5日目分です。 設定 前回とほぼ一種ですが、今回はついでにEC2 Status AlarmをCloudwatch経由でSNSでアラートを飛ばします。 SNS作成 & Subscribe（送られてくる確認メールは手動で承認） $ aws sns create-topic --name instance-alert { "TopicArn": "arn:aws:sns:us-west-2:123456789012:instance-alert" } $ aws sns subscribe --topic-arn arn:aws:sns:us-wes
ConsulによるMySQLフェールオーバー - @ijin
先日(6/22/14)、6月なのにどういう分けか早めに開催されたJuly Tech Festa 2014でConsulについて発表してきた。そのユースケースの一つとしてMySQL failoverをちょっとだけ紹介したので、ここに詳しく書いておく。 MHA MySQLレプリケーションの障害時にフェールオーバーしたい場合、MHAを使うの結構ポピュラー（日本では）だと思います。MHAは最新binlogの適用、Slaveの昇格とレプリケーションの張替えまではやってくれますが、実際のフェールオーバーの部分はユーザに委ねられていて、master_ip_failover_scriptのテンプレートをカスタマイズするか独自実装する必要があり、一般的な実現方法としてはカタログデータベースの更新かVirtual IPの切替等があります。 Virtual IPだと居残りセッションの問題や切替の保証難しかったり
#ChefConf 2014に参加してきた - @ijin
San Franciscoで行われた#ChefConfに参加してきました。 忘れないうちに忘備録的に少しメモっておく。 Day 1 Awesome Postmortems by Dave Zwieback システム障害に対して素晴らしいPost Mortem（振り返り／報告書）の書き方に関する丸一日のワークショップ 前半 まずはチームに分かれて断片的且つ関連性の不明な情報を渡される。 例えば、 Tomは紫色の家の住人より短い Jimは両隣の住人より高い 赤色の家の隣人は子供が5人いる 各メンバーは情報を全部開示できないまま、ある不明確なタスクを時間内に完了させる必要がある。しかし、紙やモノを使って情報の整理をしてはならず、口頭による連絡のみなので当然情報は錯綜しタスクは未完のまま終了。 障害時の情報不足・体制不足のシミュレーション。Nosey Neighborsと言うゲームらしい。 その後
Non-RDSなオレオレMulti-AZ MySQL Replication - @ijin
先日（5/17/13）cloudpack night #6 - Re:Generate -に参加してきました。 当日の様子はcloudpack吉田さんの以下のレポートで。 cloudpack Night #6 - re:Generate - を開催しました 私はDJを少々とLTで参加させて頂いたのでその内容になります。 オレオレMulti-AZのススメ AWS上でMySQLを使う場合、RDSはてっとり早くて良いんですが、たまにもうちょっと柔軟性が欲しい時があります。 例えば別のストーレジエンジンやディストリビューションを使ったり（Percona Server, MariaDB, TokuDB, Mronnga等）、RDSでは使えないインスタンスファミリー（hi1, m3, c1系）を使ったり、OSレベルでのチューニングができたり、スレーブのバッファプールを予め温めておいたり。等々。 しかし
AWS SSD (hi1.4xlarge) vs Fusion-IOでのMySQLベンチマーク - @ijin
（※ 追記しました - 5/19/13） 巷ではMySQL 5.6 GAが出て騒がしいですが、ちょっと前に5.5系でAWSのSSDインスタンス（hi1.4xlarge）に載せ替える案件があったので、その時に取ったベンチマークを公表します。以前Fusion-IO (ioDrive Duo)でも同じようにやったので、比較になれば。 経緯 あるウェブサービスのDBサイズが巨大でm2.4xlargeでも辛くなってきている アクセスパターンによりパーティショニングが効かない シャーディングをするにはアプリ改修が大変 数週間後に急激なアクセスが予想され、時間的余裕がない！ データサイズの急激な増加によりbuffer poolから溢れ、ディスクアクセスのさらなる発生が懸念 というわけで、時間がないのでSSDへの移行を検討し、ベンチマークを取りました。 buffer poolが徐々に足りなくなった場合のデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubのeventをLambdaで処理してSlackへ通知 - @ijin