サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
moomindani.wordpress.com
“Distributed computing (Apache Hadoop, Spark, …) Advent Calendar 2016” の 12/19 担当ということで、Spark 2.0 on EMR で Spark Streaming と Structured Streaming をやってみた結果を書きます。 この記事でやること この記事では Spark 2.0 で、現在アルファ版の Structured Streaming をやってみます。 Structured Streaming とは、Spark SQL エンジンで実現されたストリーム処理の仕組みです。 従来型の Spark Streaming は RDD を DStream とよばれる Spark Streaming 特有のモデルを導入して扱うのに対して、Structured Streaming では Spark SQL
AWSのログで遊ぼうシリーズ第4弾 – Data Pipeline x Redshift。 Redshiftは第1弾~第3弾で説明した通り、COPYコマンドでデータをロードすることができるので、単純にロードだけを考えるならRedshiftを単独で使うだけで十分です。 でも、Data Pipelineと連携して使うと、スケジューリングやエラー処理、通知など高度なデータ連携が可能です。 今回はData Pipelineを使って、ELB、S3、CloudFrontのログをRedshiftにロードします。 前提知識 Data Pipelineの利用イメージ Data Pipelineは簡単に説明するとデータ連携のためのサービスです。 GUIで表現されたマップ上でアイコンを配置していき、簡単にデータ連携を定義できます。 GUIで定義したPipelineは内部的にJSONで表現され、1クリックでJSO
この記事はPostgreSQL Advent Calendar 2014の12/15のエントリです。 今日15日目は、PostgreSQLといっても特にRDS for PostgreSQLをターゲットに、運用では欠かせない”監視”に焦点を当ててみます。 通常のサーバーで動作するPostgreSQLでは、サーバーのOSレベルの死活・パフォーマンスの監視に加え、RDBMSサービスとしての正常性の監視をするのが一般的かと思われます。 一方、RDS for PostgreSQLではサーバーのOSレベルのアクセスは制限されているため、RDSならではのちょっとしたコツが必要になります。 今回は、RDS for PostgreSQLならではの監視について考えていきます。 RDS for PostgreSQLの監視 RDS for PostgreSQLの監視では、次の2層の監視がポイントです。 DBインス
この記事は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
AWSのログで遊ぼうシリーズ第1弾 – ELB x Redshift。 今回はELBのアクセスログを対象に、Redshiftにロードしてみます。 前提知識 ELBアクセスログの有効化 方法は下記のドキュメント参照。 アクセスログの有効化 – ELB開発者ガイド ELBアクセスログの格納場所 ELBのアクセスログは、指定したS3の下記のパスに5分毎あるいは60分毎に(設定依存)出力されます。 {Bucket}/{Prefix}/AWSLogs/{AWS AccountID}/elasticloadbalancing/{Region}/{Year}/{Month}/{Day}/{AWS Account ID}_elasticloadbalancing_{Region}_{Load Balancer Name}_{End Time}_{Load Balancer IP}_{Random Stri
非常に細かい小ネタ。 ツールやスクリプトを書いていると、自サーバーのIPアドレスの文字列部分だけをパースして取得したくなることは結構あります。 ただ、パースとかめんどくさいので毎回考えるのが億劫になってしまいます。 今回はIPアドレス文字列を抽出するためのコマンドを13個紹介します。 NICがdownしたときにどうなるか等、詳細な動作確認はしてませんので、自己責任でご利用ください。 コマンドによってチェックがゆるかったり厳しかったりしますがご愛嬌ということで。 「こっちのコマンドの方がいいよ!」という方はコメント頂ければ追加しますのでぜひ突っ込みください。 hostname系 自身のホスト名で名前解決できる場合、ホスト名からIPアドレスをひいてくると手っ取り早いです。 ただし、NICを指定してIPアドレスを取得したい場合、環境の制約で名前解決できない場合は不向きです。 シンプルなhostn
またもや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/
今回も引き続きHubotネタです。 ++, –のような命令で、誰かに対して投票するようなスクリプトを実装します。 スクリプト 早速スクリプト本体です。Gistsにおいておきました。 末尾のgihyo.jpのサンプルスクリプトを参考にしてます。 # Description: # Utility commands for voting someone. # # Commands: # <name>++, <name>--, !vote-list, !vote-clear module.exports = (robot) -> KEY_SCORE = 'key_score' getScores = () -> return robot.brain.get(KEY_SCORE) or {} changeScore = (name, diff) -> source = getScores() sco
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フォームを使って、フォーム送信時のアクション(メール通知、ページ表示)を設定する方法を見ていきます。 実現できることと実現できないこと よくある要件として、フォームが送信されたときにメールを送信したい、送信完了ページをカスタマイズしたい、といったものがあります。 この観点で、できることとできないことを整理すると以下のようになります。 標準の機能で実現可能 フォームが送信された際に規定のメールアドレスにメールを送る フォーム送信完了ページで規定の内容を表示する カスタマイズすれば実現可能 フォームが送信された
前回はPacemaker(Heartbeat)で2ノードHAクラスタを構築しました。 前回説明したとおり、Pacemakerを使う場合、2種類の組み合わせがあります。 Pacemaker + Heartbeat Pacemaker + Corosync 今回は後者のPacemaker + Corosyncの構成で、(前回と同等の)2ノードHAクラスタを構築してみます。 環境 今回使用したのは下記のインスタンスです。(前回と同じです。) Red Hat Enterprise Linux 6.4 (PV) 64bit (t1.micro) Pacemakerパッケージとしては、Linux-HA Japan提供のPacemaker 1.0.13-1.2を使用します。 2台のインスタンスのIPアドレス、ノード名はそれぞれ下記とします。 IP:172.31.15.101, node:ip-172-3
今回はAWS上のHAについて考えます。 AWSクラウドデザインパターンにもありますが、AWS上で最もよく使われる可用性向上のための構成は、ELBでアクセスを複数サーバに振り分けるMulti-Serverパターンでしょう。 WEBサーバ等ならこれでOKなのですが、使いたいソフトウェアによってはマッチしない場合があります。 このような場合、EC2上でHAミドルを使うことで要望を実現できたりします。 今回はAmazon EC2上で、2ノードHAクラスタを構築してみます。 HAミドルとして広く使用されているPacemakerを使用します。 Pacemakerのクラスタ制御には、HeartbeatあるいはCorosyncが使用されます。 つまり、Pacemakerを実際に使う場合、2種類の組み合わせがあります。 Pacemaker + Heartbeat Pacemaker + Corosync 今
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でテスト済みです。 なお、本スクリプトは
AWSのLinuxインスタンスのCPU, メモリ, ディスク, ロードアベレージ等をCloudWatchで監視するスクリプトを作ってみた 前回、前々回とAmazon CloudWatch Monitoring Scriptsについて見てきました。 今回は、LinuxのCPU, メモリ, ディスク, ロードアベレージ等をCloudWatchで監視するスクリプト、aws-mon-linuxを作ってみました。 特徴は下記の通り。 Amazon CloudWatch Monitoring Scripts for Linuxとほぼ同一のオプションを用意しているので、同等の操作感で使えます。 Amazon CloudWatch Monitoring Scripts for Linuxで監視可能なメモリ、ディスクに加えて、さらにCPUのsystem,user,wait等の詳細な値やロードアベレージ等まで
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
次のページ
このページを最初にブックマークしてみませんか?
『moomindani.wordpress.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く