タグ

ブックマーク / ijin.github.io (5)

  • 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の

  • AWS re:Invent 2015に参加してきた - @ijin

    今年で3度目の参加となるAWS re:Invent。 忘れない内に記録を残しておきます。 Day 0 Game Day Unicornを貸し出すサービスを展開する仮想のスタートアップ企業にDevOpsチームとして最近入社したという設定。前任者が退職しており、資料が少ない中でサービスオープンに立ち会いつつ、様々な困難に直面するというフルデイ・イベント。 今までのGame Dayと違って面白いのはパフォーマンス・チューニングをしつつも、コストも意識しながらチーム間でスコアを競争するところ。アプリは触れないので、ISUCONよりは昔やったチューニンガソンに近い感じ。 スコアは累積の損益。アーキテクチャによっては利益が出たり損失が出たりする。例えば、多くのリクエストが処理できると利益は増すが、AWSのリソースが多いと費用が掛かって損失になりうる。 当然最初は各チームは赤字から始まり、時間とともに積

  • Auto Scalingによる自動復旧(AWS Lambda+SNS編) - @ijin

    先週のAWS Summit San Fransiscoにて、ついにLambdaSNSに対応しました。 様々なサービスが発表された中、個人的にはこれが一番のヒットです!というのも、この機能によってAWS間のサービスがより連携しやすくなり、新しいリアクティブなアーキテクチャをどんどん実現できそうだからです。 というわけで、少し試してみました。 お題は去年12月に試したAutoScaling + Lambda。(当時はLambdaはまだこの機能がなかったのでSNS→SQSにてイベントをプロセスする仕組みを作りました。) SNS連携によって前回のこれが こうなります。(Lambdaのアイコンが出たので差し替えてます) うーん、シンプル! 設定 前回とほぼ同様。 SNS作成

    clavier
    clavier 2015/04/17
    Auto Scalingによる自動復旧(AWS Lambda+SNS編) - @ijin
  • 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だと居残りセッションの問題や切替の保証難しかったり

  • 1