はてなブックマーク

この記事はAWS Lambda Advent Calendar 2014の12/8のエントリです。 昨日7日目のエントリはmaroon1stさんの「今後のLambdaの機能拡張に対する要望を挙げてみた – AWS Lambda Advent Calendar 2014：7日目」でした。 今日8日目は、LambdaでS3上に出力されたログをCloudWatch Logsに取り込んで監視してみます。 CloudWatch Logsはログの蓄積や監視を実現するためのサービスとして、2014年7月にリリースされました。 現時点では、Linuxでは任意のログファイルの監視に、Windowsでは任意のログファイルに加えてWindows Eventlog・Event Tracing for Windowsの監視にも対応し、CloudWatch Logsは既にEC2インスタンス内部のログの大部分に対応して

AWSのログで遊ぼうシリーズ第2弾 – S3 x Redshift。 今回はS3のアクセスログを対象に、Redshiftにロードしてみます。 前提知識 S3アクセスログの有効化 方法は下記のドキュメント参照。 コンソールを使用したロギングの有効化 – S3開発者ガイド S3アクセスログのフォーマット S3のアクセスログは、スペース区切りで1行に1リクエストが記録されます。 各行には下記のフィールドが含まれます。（公式ドキュメントの抜粋です。） フィールド名 説明 bucket_owner 配信元バケット所有者の正規ユーザー ID。 bucket リクエストの処理対象のバケットの名前。システムで受け取ったリクエストの形式に誤りがあり、バケットを特定できない場合、そのリクエストはサーバーアクセスログに表示されません。 request_timestamp リクエストを受け取った時刻。形式は st

またもやHubotネタです。 ＃最近Hubot弄ってるだけで他のこと全然できてない・・・ 今回は、投稿されたURLのTitleをつぶやくスクリプトを実装します。 スクリプト 早速スクリプト本体です。Gistにもおいておきました。 下記を参考にさせていただきました。 HubotでURLが貼られたらページのタイトルをしゃべるようにする request = require 'request' cheerio = require 'cheerio' iconv = require 'iconv' convertEncode = (body) -> charset = body.toString('ascii').match /<meta[^>]*charset\s*=\s*["']?([-\w]+)["']?/i return new iconv.Iconv(charset[1], 'UTF-8/

EC2では、Quick StartやAWS Marketplace、Community AMIsなど、様々なAMIからインスタンスを作成できます。 選択肢がたくさんあるのは素晴らしいですが、気をつけないと素性の知れないAMIを意図せず使ってしまうことになりかねません。 使いたいOSの、できるだけオフィシャルなAMIが欲しいというのが人情というもの。 （ここでいうオフィシャルというのは、Amazon公式に限りません。） そこで、OSごとのEC2オフィシャルAMIを一覧にまとめてみました。 Amazon Linux マネジメントコンソールからAmazon提供のPublic AMIの一覧が見れます。 こちらのリンクからどうぞ。 https://console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Images:filter=amazon

本日松戸で開催された「JAWS-UG 千葉支部 Vol.4 – AWS運用縛り」に参加してきましたので、参加メモをエントリにしておきます。 あくまで個人的な参加メモですので、内容については公開される（はずの）各プレゼンのスライドをご覧ください。 ちなみに、Togetterでまとめていただいたものはこちら。 「クラメソ保守運用担当からみたAWS使っててよかったこと」クラスメソッド株式会社 植木 和樹さん@czkuk 保守と運用 保守＝「システムをあるべき状態に保つ」 運用＝「正常に稼働しているシステムを用い手順やルールに従って実施する業務」 ⇒面倒は全部AWSに任せる AWSの障害復旧：EC2 Stop⇒Start 再起動すればサービス再開する作りにしておく・・・これはアプリケーション開発者の責任 AutoScalingでAutoHealingしとくと安全 AWSの障害原因調査：AWSサポー

先日リリースされたCloudWatch Logs、監視ツールを開発していた者としては注目せざるを得ません。 特に、ログ監視エージェントにはこだわりがあるので、CloudWatch Logsエージェントの細かな動作に興味をもちました。 そこで、今回はCloudWatch Logsエージェントを5つの観点から検証してみました。 はじめに ログ監視エージェントにとって重要な5つのポイントを考えてみました。 メッセージラッシュ ロングメッセージ ログローテーション 一時的な通信断 エージェント停止 メッセージラッシュ 障害発生時等に短時間に大量のメッセージが発生することをメッセージラッシュと呼びます。 このメッセージラッシュが発生した際にも、安定して動作してメッセージをロストせずに監視できることは、ログ監視エージェントにとって重要なポイントです。 そこで、メッセージラッシュを意図的に発生させ、ロス

AWS Summit 2014 New Yorkで発表された、CloudWatch Logsについて試してレポートします。 CloudWatch Logsエージェントのセットアップ 早速セットアップしましょう。 …と思いきや、早速クラスメソッドさんのブログに先を越されました。 Amazon CloudWatch Logsでログファイルを監視する – Developers.IO 上の記事では既存のインスタンスにCloudWatch Logsエージェントをインストールする方法を試しているので、こちらでは新規インスタンスでCloudWatch Logsエージェントをインストール・セットアップする方法を試します。 Quick Start: Install and Configure the CloudWatch Logs Agent on a New EC2 Instance Step1. コンフ

AWSやMicrosoft Azure, Googleなどのクラウド上ではIPマルチキャスト/ブロードキャストの通信が使えないのは有名な話です。 自分としては、Corosyncでマルチキャストを使いたい、というのがきっかけでマルチキャストについて考えはじめました。 （もちろんユニキャストも使えるのですが、マルチキャストにすると設定が簡単になったり、いろいろと便利なのです。） 今回はAWS EC2-VPCでIPマルチキャスト/ブロードキャストを実現することを考えてみます。 なんでマルチキャストを使いたいの？ 今日、インターネットのトラフィックのほとんどはユニキャストによって行われていますが、用途によってはマルチキャストが望ましい通信もあります。 まずは、High Availabilityの分野で、代表的なソフトウェアとしてはCorosyncやKeepalived、uCarp、JGroupなど

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

CloudWatchはAWSで用意されている監視サービスで、パフォーマンスやシステムの状態を監視することができます。 このCloudWatchによる監視は数値の監視を対象としているため、一般的な監視ツールでよくある”ログ監視”をすることはできません。 ※ここでの「ログ監視」は、ログファイルに出力されるメッセージをあらかじめ定義したパターンと比較して、マッチしていればアクションを起こすタイプの監視を意味するものとします。 そこで、今回はEC2 Linuxのログ監視をlogmonというツールとCloudWatchを組み合わせる形で実現してみます。 ログファイルを監視する方法 ログファイルの監視は昔から様々なツールで実現されてきました。 ここで、ログファイル監視を実現するための代表的な方式を挙げてみます。 swatch LogWatch logmon Nagios Zabbix Hinemos

AWSでは昔からあるEC2やS3などに加え、最近ではWorkspaces、AppStreamなど、数多くのサービスが登場しています。 今回は、AWSでブラウザから複数のサービスを使うときに便利なawsfaviconizeを紹介します。 AWSではベストプラクティスとして、複数のサービスを組み合わせたアーキテクチャを設計し、システムを実現することが多いと思います。 そのような際、ブラウザで多くのタブを開くことになり、こんなことになります。 見ての通り、同じようなタブが大量に並び、視認性がとても悪く、 「どのサービスをどのタブで開いてたんだっけ・・・？」となりがちです。 こんなとき、@tsuzy_ さん作の”awsfaviconize“を使うと、 タブのfaviconがAWSの各種サービスのfaviconとなり、区別しやすくなります。 実際に全部のサービスを同時に使うことはないと思いますが、こ

AWS EC2 Linuxを利用する際、SSHでログインして利用することになりますが、 端末の所属するネットワークからAWS VPCに対するVPN等を利用できない場合、 EC2インスタンスのSSH(TCP 22)ポートをインターネットに公開することになります。 このようなケースに考えられるリスクと回避方法について考えていきます。 リスク AWS EC2 Linuxに設定したSecurity Groupで、下記のようにSSHをAnywhere(0.0.0.0/0)に対して開放したとします。 このような場合、どういったリスクが考えられるでしょうか。 もちろん、EC2 Linuxに対するSSHログインにはキーペアが必要になるので、誰からでもログインできる状態ではありません。 ですが、万一キーペアが流出してしまった場合、クラッキングを受けた場合、SSHに脆弱性が発見された場合など、 様々なリスクを

懲りずに4回目のPacemaker on AWSネタです。 前回はPacemakerでパブリックIPアドレスであるEIPを付け替えてAWSクラウドデザインパターンのFloating IPパターンを実現しました。 今回はEIPではなく、仮想NICであるENIを付け替えるRA(Resource Agent)を書いてみました。 冒頭で先に言っときますが、今回のRAはあまり実用的ではなく、いろいろ弄ってみた結果生まれただけのものなので、実用的なRAをお求めの方は前回の記事をご参照ください:D aws-eni-resource-agentという名前でGithubに置いておきました。 例によってバグ報告、Pull Request、大歓迎です。 ちなみに過去のPacemakerネタはこちら。 PacemakerでEIPを付替えるResource Agentを書いてみた EC2上でPacemakerによる

3回目のPacemaker on AWSネタです。 今回は、AWSクラウドデザインパターンのFloating IPパターンを実現するために、PacemakerでEIPを付替えるRA(Resource Agent)を書いてみました。 aws-eip-resource-agentという名前でGithubに置いておきました。 例によってバグ報告、Pull Request、大歓迎です。 ちなみに過去のPacemakerネタはこちら。 EC2上でPacemakerによる2ノードHAクラスタを構築する(Heartbeat編) EC2上でPacemakerによる2ノードHAクラスタを構築する(Corosync編) 以下で詳細について説明していきます。 環境 今回使用したのは下記のインスタンスです。 Red Hat Enterprise Linux 6.5 (PV) 64bit (t1.micro) Pa

最近、AWS Elastic BeanstalkでDockerがサポートされたということで、試しに使ってみます。 マネジメントコンソールからElastic Beanstalkにアクセスします。 初めての場合は”My First Elastic Beanstalk Application”というアプリケーションがあるので、そこにある”Create one now”をクリックします。 Environment Typeを設定します。 今回はDockerを試したいだけなので、下記のように設定しました。 Environment tier : Web Server Predefined configuration : Docker Environment type : Single instance Application Versionを設定します。 今回はあらかじめ用意されているSample Ap

今回は打って変わってGoogleフォームの話。 最近、あるイベントの参加申し込みフォームを作っていたので、備忘録として残します。 イベントの申し込みフォームを作りたい場合などに便利なGoogleフォームですが、 込み入った内容を実現しようとすると工夫が必要になります。 今回はGoogleフォームを使って、フォーム送信時のアクション（メール通知、ページ表示）を設定する方法を見ていきます。 実現できることと実現できないこと よくある要件として、フォームが送信されたときにメールを送信したい、送信完了ページをカスタマイズしたい、といったものがあります。 この観点で、できることとできないことを整理すると以下のようになります。 標準の機能で実現可能 フォームが送信された際に規定のメールアドレスにメールを送る フォーム送信完了ページで規定の内容を表示する カスタマイズすれば実現可能 フォームが送信された

Amazon RDS for PostgreSQLのキャッシュヒット率, セッション数等をCloudWatchで監視するスクリプトを作ってみた 前回はEC2のLinuxインスタンスのCPU, メモリ, ディスク, ロードアベレージ等を監視するスクリプトを作った話でした。 今回はEC2以外の監視ということで、Amazon RDS for PostgreSQLのキャッシュヒット率, セッション数, トランザクション数等をCloudWatchのカスタムメトリクスで監視するスクリプト、aws-mon-pgsqlを作ってみました。 こちらもGitHubで公開しました。バグ報告、Pull Request、大歓迎です。 以下で詳細について説明していきます。 どんな環境で使えるの？ Amazon RDS for PostgreSQLのPostgreSQL 9.3.3でテスト済みです。 なお、本スクリプトは

Amazon CloudWatch Monitoring Scripts for LinuxでLinuxインスタンスのメモリとディスク領域を監視する EC2インスタンスを監視するには、CloudWatchが便利です。 このCloudWatchでは、標準で監視できる項目は限られますが、それを補うスクリプトとしてAmazon CloudWatch Monitoring Scriptsが提供されています。 Amazon CloudWatch Monitoring Scriptsには下記の2種類があります。 Amazon CloudWatch Monitoring Scripts for Linux Amazon CloudWatch Monitoring Scripts for Microsoft Windows Server 今回は、前者のAmazon CloudWatch Monitorin

JAWS DAYS 2014が近くなってきたので、AWSを弄って遊んでます。 今回は、Amazon EC2インスタンスから、Amazon S3のバケットをファイルシステムとしてマウントしてみます。 はじめに Amazon EC2インスタンスから、S3のバケットをファイルシステムとしてマウントするためには、 s3fs-fuseというツールを使います。 s3fs-fuseとは、S3のバケットをローカルのファイルシステムとしてマウントする、FUSEファイルシステムです。 FUSE(Filesystem in Userspace)は、Unix系OSのカーネルモジュールで、 ユーザーが独自のファイルシステムを作成できる機能を提供するOSSです。 （詳しい説明は公式サイトとWikipediaに譲ります。。） これを使って、ローカルに存在しないS3バケットのデータをファイルシステムとしてOSに扱わせてい

今回は、前々から気になっていたOpenVNetをいろいろと弄ってみます。 なお、このエントリは、Wakame Users Group Advent Calendar 2013の12/22分の記事となっています。 OpenVNetって何？ OpenVNetはエッジオーバレイ型の仮想ネットワークを作るOSSです。 主な構成要素は下記の4つです。 vna vnmgr vnapi(webapi) vncli 詳しくは、あくしゅの山崎さんのSlideShareを見るとよくわかります。 とりあえずインストールしてみる まずは、何はともあれインストール。 つい先日公開されたInstallGuideの”Let’s try 1Box OpenVNet”を参考に、下記の環境にインストールしました。 # uname -a Linux openvnet 2.6.32-358.el6.x86_64 #1 SMP F