Elastic Beanstalk は2016年12月にアップデートされたプラットフォームから、CloudWatch Logs との連携が強化され、コンソールからオプションを有効にするだけで、簡単にログが Stream に出力できるようになりました。 ただ、例えば Tomcat 環境であれば現時点では以下のログが対象になり、catalina.out が含まれません。 /var/log/eb-activity.log /var/log/httpd/error_log /var/log/httpd/access_log /var/log/nginx/error_log /var/log/nginx/access_logということで、catalina.out を CloudWatch Logs に出力するために、以下のファイルを .ebextensions に含める必要があります。 cwl-ca

Lambda のログは自動的に CloudWatch Logs に保存されますが、他と連携する場合は S3 のほうが何かと都合がいいです。 CloudWatch Logs にはログデータを一括で Amazon S3 にエクスポートする機能があります。リアルタイム性が求められずバッチ処理で定期的にエクスポートする用途に向いています（リアルタイム性が求められる場合は、サブスクリプションを使用したログデータのリアルタイム処理が用意されています）。 というわけで Lambda と CloudWatch Events を使って、CloudWatch Logs から S3 へ自動的にエクスポートしてみます。 CloudWatch Logs API の CreateExportTask S3 へのエクスポートは CloudWatch Logs API の CreateExportTask を使います。

まいど、大阪の市田です。 CloudWatchのアラームをSlackに通知するという構成は、最近ではよくある話でその方法もたくさんあります。 今回は、ゼロからLambda関数を作るのではなく、事前に用意されている「Blueprint」を使います。 このBlueprintは昨年から公開されていますが、Blueprintの内容は随時アップデートされており、現在はKMSを使って、SlackにPOSTするURLを暗号化しています。 その設定もマネジメントコンソール上で簡単にできるようになっていたので、最新内容を踏まえてご紹介したいと思います。 概要 今回利用するBlueprintは「Cloudwatch-alarm-to-slack」 です。 構成は下記の通りで、「CloudWatchのアラームをAmazon SNSに送り、Lambdaを起動する」という形になります。 ## 作業手順 大まかな作業

第7回となるJAWS-UG岡山勉強会の前半は、AWS Elastic Beanstalkを使った自動化の話が3連発。複数サーバーの運用に携わったこともなく、AWSの機能を試すにもGUIのManagement Consoleからしかサービスを起動したことのない筆者にとっては理解の難しいセッションが続いた。しかしさすがは中の人。AWS ソリューションアーキテクトの藤原 吉規さんはわかりやすくElastic Beanstalkの概要を説明してくれた。セッション後半では運用自動化に欠かせないCloudWatchを使った監視手法の解説もあった。 前半は難波さんを皮切りに3人続けてElastic Beanstalkによる自動化の話 しょっぱなから2セッション続けてElastic Beanstalkの話を聞き、テクニカルな部分に理解が及ばず、筆者の脳みそは水を吸いすぎたスポンジのようになっていた。もうこ

遭遇した状況 今回は中でも ElastiCache プライマリクラスターのみで障害が発生した場合 の話しです。 ドキュメントにもあるように、マルチAZ 環境での自動フェイルオーバーでの今回の状況においては 書き込みは、昇格プロセスが完了するとすぐに (通常は数分) 再開できます。ElastiCache が昇格したレプリカの DNS を反映させるため、書き込みのためのエンドポイントを変更する必要はありません。 となっています。 ポイントは、「DNS を反映させるため、書き込みのためのエンドポイントを変更する必要がありません」というところです。 発生した課題 自動フェイルオーバーが発生した際に、運用している Rails アプリから上記のエラーが止まらないと言う状況になりました。 最終的には、Web アプリ、ワーカーアプリともに、再起動することで状況は改善しました。 このエラーメッセージから分か

目的 ElastiCacheでRedisClusterを作成し接続確認を行います。 前提条件 今回はClusterモードを有効な状態で作成します。 ※Clusterモードの説明に関してはこの記事では割愛させて頂きます。 こちら に記載されています。 事前準備 必要な事前準備は下記の通りになります。 ※Clusterを作りながらでも、進められるのですが、今回は事前に必要な物の作成を行っておきます。 Clusterに割り当てるサブネット、サブネットグループ Clusterに適応するセキュリティグループ サブネットの作成 ElastiCacheが利用するサブネットの作成を行います。 対障害性を向上させる為に、東京リージョンの ap-northeast-1a と ap-northeast-1c の2つのアベイラビリティーゾーンにサブネットを構築します。 ネームタグ: dev-session-red

はじめに Web サイト表示速度向上の一環として、仕事で、ElastiCache + Redis によるキャッシュ層を導入する。 導入にあたり、ElastiCache + Redis で利用するノードタイプ（インスタンスタイプ）や、制限などの事前調査が必要になった。 ElastiCache + Redis は、ノードタイプやクラスタの種類によって、機能サポートが異なり、混乱するところが多々あったため、AWS のドキュメントを参考に、分かりにくいところをまとめた。 これから導入する段階なので、AWS のドキュメントの内容以上のことは書いていません。 運用についてとか、ハマったところなどの記述はありません。 内容におかしいところがあれば教えてください 概念 実際に使うかどうかに関わらず、シャードやレプリカという用語がバンバンでてくるので、まとめる。 参考: http://docs.aws.am

こんにちは、貴子です。 dockerを使ったコンテナ化をしたいというプロジェクトがあったので、ECSの導入検討をしました。 その際に作成したcloudformationのtemplateを載せます。 ECSを選んだ理由は？ AWSでdockerのサービスは2つ、AWS Elastic BeanstalkとECSがあります。 何がどう違うの？というところが解らなかったので、AWSのソリューションアーキテクトの方に弊社へ来ていただいてサービスのご紹介を頂きました。 Beanstalkの中でECSが動いているので大きな違いはありませんが、Beanstalkの方は元々PaaSなので、色々元々組み込まれて便利に使え、.ebextensionsというYAMLで管理できるようになっていいます。 ECSはdockerに特化したもので、最新機能はECSの方が組み込まれるのが早いそうです。 .ebextens

Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」リリースを発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 SpinnakerはもともとNetflixが開発し、2015年にオープンソースとして最初のバージョンを公開しています。 参考：Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開 このときすでにNetflixの開発にGoogleは参加しており、その後もSpinnakerの開発が進められてきました。 Spinnakerはデプロイに求められるほとんどすべての機能を備えていると、次のように説明されています。 In Spinnaker, deployments are orchestrated using custom release pipelines,

APNs に Push する配信サーバーの課題 みなさま、Amazon SNS (※以降 SNS) は活用されていますでしょうか？ APNs (Apple Push Notification service) を利用してサーバーから iOS デバイスに Push 通知を送りたい、という要件はよくあると思います。 しかし次の記事にあるように、APNs の仕様上 エラーが発生したあとの Push 通知が無効になる という問題があります。ヘタすると 10 万ユーザーに送っているつもりが 1,000 ユーザーにしか届いていないという問題にもなりかねません。 Apple Push Notification Serviceのエラー処理について | hagino3000's blog また、APNs の仕様を読んでみると、次のような記述があります。 If you send a notification

AWS meets Android - "AWS SDK for Android"で開発を楽にしよう！SORACOM, INC