Fluentd + Elastichsearch + Kibana(3)FluentdからElasticsearchへの転送

Fluentdの設定

前回までにFluentd + Elastichsearch + Kibanaの環境設定と、ログの送信元となるMacの設定を行った。

今回は、受信したデータをElasticsearchに転送する処理を扱う。設定は以下の通り。

sudo vi /etc/td-agent/td-agent.conf

<source>
  @type forward
</source>

<match example.app>
  type elasticsearch
  host localhost
  port 9200
  type_name exampleapp
  logstash_format true
</match>

type_nameは、Elasticsearchタイプ名を指定する。識別できる文字列なら好きに指定して良いようだ。logstash_formatは、logstashフォーマットで出力するオプションで、とりあえず今回はtrueにしておく。

Fluentdの再起動

Fluentdを再起動する。

sudo systemctl restart td-agent

Kinabaにアクセス

Kibanaにアクセスすると、データの受信に伴って、インストール直後とは表示が変わっている。ログインすると受信データが確認できる。

http://XXX.XXX.XXX.XXX:5601

  • インストール直後
    Kibana
  • データ入力完了後
    Kibana

Fluentd + Elastichsearch + Kibana(2)MacでFluentdを動かそう

インストールと起動

MacにFluentdをインストールし、Macで動くアプリのログを、Elastichsearchが動くサーバへと転送する。FluentdのダウンロードページにMac用のdmgイメージがあるので、これをダウンロードし実行する。

Mac Fluentd dmg

Macのデーモンは、launchctlと呼ばれるツールで管理される。launchctlは、設定ファイル(plist)のロードによってデーモンを登録し、デーモンの開始や終了など制御する。通常は、デーモンの登録を行った上で、デーモンの開始を行うという流れとなるが、設定ファイル内で「RunAtLoad = true」が設定されている場合は、ロードと同時にデーモンが起動され、OSの起動時にも自動的にデーモンは起動する。

Fluentd(td-agent)の設定ファイルは、「RunAtLoad = true」に設定されているため、設定ファイルをロードするだけで、デーモンは起動され、自動起動に設定される。

launchctl load /Library/LaunchDaemons/td-agent.plist 

元データの設定

Fluentdは、元データの指定と転送先の指定が必要となる。元データは以下のような種類を指定できる。

ログファイルから取得する

転送ログの元データを指定する。設定するパラメータは以下の通り。

パラメータ 意味
type tail
path ログファイルのパス
pos_file 読み込んだ位置を記憶しておくファイル
tag ログの識別子
<source>
  type tail
  format apache
  path /var/log/httpd-access.log
  tag td.apache.access
</source>

httpから取得する

http通信によってデータを取得する。設定するパラメータは以下の通り。

パラメータ 意味
type http
port ポート番号

tagは、URLヘッダで指定する。

<source>
  type http
  port 8888
</source>

実行したコマンドの標準出力から取得する

コマンドの実行によってデータを取得する。設定するパラメータは以下の通り。

パラメータ 意味
type exec
command 実行するコマンド
tag ログの識別子

他のFluentdから取得する

他のFluentdから転送されたデータを受信する。設定するパラメータは以下の通り。

パラメータ 意味
type forward
<source>
  type forward
</source>

設定例

今回は、Macで動作するアプリが出力する以下の形式のログを元データに指定する。

2016-08-11 04:56:31.518 exampleApp[321:2853] <Normal> "Application is started."
2016-08-11 04:56:31.518 exampleApp[321:2853] <Normal> "Application is initialized."
2016-08-11 04:56:31.518 exampleApp[321:2853] <Normal> "Data is received: apple=3, orange=4"
2016-08-11 04:56:31.518 exampleApp[321:2853] <Normal> "Application will be terminated."

Fluentdは様々なログをJSON形式に変換した上で転送を行う。ログの変換を行うためには、どのようなフォーマットでログが記述されているかを正規表現でFluentdに教えてあげる必要があり、この設定が最も難しい。今回のログは、スペース区切りで、[日付][プロセス情報][ステータス][メッセージ]の情報が並んでいるので、正規表現で表現すると以下のようになる。

sudo vi /etc/td-agent/td-agent.conf

<source>
  type tail
  path /tmp/exampleApp.log
  pos_file /var/log/td-agent/exampleApp.log.pos
  tag example.app
  format /(?<time>[^\]]*) (?<process>.*) <(?<stat>.*)> "(?<message>.*)"/
  time_format %Y-%m-%d %H:%M:%S.%N
</source>

出力先の設定

Fluentdは、出力先も様々な方法を選択できる。

標準出力に転送

データを標準出力に転送する。設定するパラメータは以下の通り。

パラメータ 意味
type stdout
<match **>
  type stdout
</match>

ファイルに転送

データをファイルに転送する。設定するパラメータは以下の通り。

パラメータ 意味
type file
path 出力ファイルのパス
time_slice_format ファイル名のサフィックス
time_slice_wait ファイルを分割する時間単位
<match **>
  type file
  path /var/log/fluent/exampleApp.export
  time_slice_format %Y%m%d
  time_slice_wait 10m
</match>

他のFluentdに転送

データを他のFluentdに転送する。設定するパラメータは以下の通り。

パラメータ 意味
type forward
server 転送先サーバの情報

今回は、Macアプリのログを、Elasticsearchを導入した他のサーバに転送したいので、以下の設定とした。

<match **>
  type forward
  <server>
    name server_1
    host XXX.XXX.XXX.XXX
  </server>
</match>

設定ファイル

設定ファイルは以下となった。

sudo vi /etc/td-agent/td-agent.conf

<source>
  type tail
  path /tmp/exampleApp.log
  pos_file /var/log/td-agent/exampleApp.log.pos
  tag example.app
  format /(?<time>[^\]]*) (?<process>.*) <(?<stat>.*)> "(?<message>.*)"/
  time_format %Y-%m-%d %H:%M:%S.%N
</source>

<match **>
  type forward
  <server>
    name server_1
    host XXX.XXX.XXX.XXX
  </server>
</match>

Fluentdを再起動して新たな設定ファイルを読み込む。このとき、/var/log/td-agent/td-agent.logに正常なログが吐き出されていたらOK!

launchctl unload /Library/LaunchDaemons/td-agent.plist 
launchctl load /Library/LaunchDaemons/td-agent.plist 

参考になるページ

CentOS7(1)アレイコントローラの認識

HP Dynamic Smart Array B140i Controller

CentOS7をインストールするサーバに、アレイコントローラが搭載されている場合、アレイコントローラのドライバを指定した上でインストールを実行しないと、論理ドライブが認識されずに物理ドライブがそのまま見えてしまう場合がある。HP ProLiantに搭載されているHP Dynamic Smart Array B140i Controllerを認識させる場合は、デバイスドライバの入ったUSBメモリを作成し、このUSBメモリを使ってCentOSインストールと同時にドライバの組み込みも行う。デバイスドライバは、HPのサポートページからダウンロードすることが可能である。

デバイスドライバ(ドライバディスケット)のダウンロード

HPのサポートページから「.gz」形式のドライバーをダウンロードする。

デバイスドライバのダウンロード

デバイスドライバー(ドライバディスケット)の解凍

解凍すると「.dd」形式のファイルとなる。

デバイスドライバの解凍

USBメモリへの書き込み

FAT形式にフォーマットしたUSBメモリにddコマンドを用いてドライバを書き込む。「.dd」形式のファイルをファインダー上でドラッグアンドドロップするだけでは、正常に読み込むことができない

FAT形式にフォーマット

Macの場合は、ディスクユーティリティを使ってFAT形式にフォーマットする。このとき、名前をUNTITLEDと命名すると、通常は/Volumes/UNTITLEDでマウントされる。また、装置欄に記述されている名称(disk2)がデバイス名称(/dev/disk2)となる。

USBメモリのフォーマット

ddコマンドによる書き込み

USBメモリがマウントされている状態では、ddコマンドを実行することができない。

$ sudo dd if=hpdsa-1.2.8-107.rhel7u0.x86_64.dd of=/dev/disk2
Password:
dd: /dev/disk2: Resource busy

そこで、ddコマンドを実行する前に、USBメモリをアンマウントしておく。

$ sudo umount -fv /Volumes/UNTITLED

改めて、ddコマンドを実行する。

$ sudo dd if=hpdsa-1.2.8-107.rhel7u0.x86_64.dd of=/dev/disk2
2584+0 records in
2584+0 records out
1323008 bytes transferred in 0.654908 secs (2020143 bytes/sec)

CentOSをインストール

CentOSをインストールする際にGRUBエントリーの編集を行い、デバイスドライバーのインストールとAHCIの無効化を行う。

GRUB選択画面

eコマンド”で編集画面に遷移し、”inst.dd modprobe.blacklist=ahci“を追記した上で起動を行う。この時点では、まだUSBメモリを挿入しない

vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=CENTOS\X207\X20\X86_64 quit inst.dd modprobe.blacklist=ahci


すると、どのデバイスからドライバをインストールするかを問うプロンプトが表示されるので、**この時点で初めてUSBメモリを挿入**し、”**rコマンド**“によりデバイス一覧の再スキャンを行う。


DD: starting interactive mode

(Page 1 of 0) Driver disk device selection
    /DEVICE TYPE      LABEL
# to select, 'r'-reflesh, or 'c'-continue:

USBメモリが認識されるので、どのデバイスにある、どのドライバを組み込むのかを対話形式で入力する。

(Page 1 of 1) Driver disk device selection
	/DEVICE	TYPE	LABEL
1)	sda1	vfat	VID	XXXXX
2)	sda2	ext4	OEMDRV	XXXXX
# to select, 'r'-reflesh, or 'c'-continue: 2
DD: Examining /dev/sda2

(Page 1 of 1) Select drivers to install
1)	[]	/media/DD-1/rmps/x86_64/kmod-hpdsa-1.2.8-107.rhel7u2.x86_64.rpm
# to toggle selection, or 'c'-continue: 1

(Page 1 of 1) Select drivers to install
1)	[x]	/media/DD-1/rmps/x86_64/kmod-hpdsa-1.2.8-107.rhel7u2.x86_64.rpm
# to toggle selection, or 'c'-continue: c
DD: Extracting: kmod-hpdsa

これでドライバの組み込みが終了したので、この時点で必ずUSBメモリを抜いておく。USBメモリを挿したままインストール作業を実行すると、USBメモリからOSインストールを行おうとしてエラーが発生する。

HP Smart Array P440 FBWC Controller

SAS HDDのアレイコントローラであるP440は、何もしなくてもCentOSから認識された。違いはなんなんだ。

AWS CloudWatch(2)システム運用における監視項目

AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多い。様々な監視項目が存在するが、システム運用を行う際に特に監視する必要のある項目は以下の通り。

DynamoDB

多くの項目がデフォルトで 1 分ごとにデータを送信するが、5 分間隔で送信されるデータも存在する。事前に設定した容量(スループット)が十分であるかを監視しておくと良い。

  • ProvisionedReadCapacityUnits
  • ConsumedReadCapacityUnits
  • ProvisionedWriteCapacityUnits
  • ConsumedWriteCapacityUnits

EC2

Amazon EC2 はデフォルトで 5 分ごとに CloudWatch にデータを送信する。インスタンスを作成する際に、「詳細モニタリングを有効」にチェックを入れることでこれを 1 分ごとに変更することができるCPU使用率を監視しておくと良い。

  • CPUUtilization

Kinesis

事前に設定した容量(シャード数)が十分であるかを監視しておくと良い。

  • PutRecords.Records
  • IncomingRecords
  • GetRecords.Bytes

AWS CloudWatch(1)CloudWatchとは何なのか

CloudWatchとは

CloudWatchは、AWSの各リソースを監視することのできるサービスである。AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多く、Zabbixなどの他の監視環境を構築する必要がない。フルマネージドのサービスの場合は自ら監視環境を構築することができないため、CloudWatchによる監視が必須となる。また、CloudWatch Logsを用いることで、各リソースのLogデータをCloudWatchで監視することが可能になる。CloudWatch Logsは、ログデータを無期限で保存する

CloudWatchは、NameSpaceと呼ばれるAWSサービス単位の項目とMetricsと呼ばれる監視内容から構成され、これらを組み合わせて指定することで任意の項目を確認することが可能となる。CloudWatch上のデータ(CloudWatch Logsのデータを除く)は最長2週間保存され、データの更新間隔は最短1分となっている。また、アクション機能を用いて、各アラームに対する通知やAutoRecovery, AutoScaleなどのアクションを規定することも可能である。

CloudWatch Logs Agentのインストール

EC2インスタンスにCloudWatch Logs Agentをインストールすることで、任意のログをCloudWachに送信することが可能となる。AmazonLinuxを使用する場合には、以下の手順でインストールする。

CloudWatch Logs Agentのインストール

CloudWatch Logs Agentはyumから簡単にインストールできる。

yum update -y
yum install -y awslogs

CloudWatch Logs Agentの設定

監視対象のログはconfファイルで設定する。

sudo vi /etc/awslogs/awslogs.conf

標準で/var/log/messagesの情報は送られる設定になるようである。
その下に下記のように設定を追記することで、任意のログを送ることが可能となる。

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

[test-app-log]
file = /home/ec2-user/test-app/process_log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /home/ec2-user/test-app/process_log

CloudWatch Logsのログデータをエクスポートする

CloudWatch Logsに蓄積したログデータは、S3に一括エクスポートすることができる。詳しくは、「CloudWatch コンソールを使用してログデータを Amazon S3 にエクスポートする」を参照のこと。

‘openssl/pkcs7.h’ file not found への対応

‘openssl/pkcs7.h’ file not found

XCode 7からOpenSSLライブラリを使用する場合に、‘openssl/pkcs7.h’ file not foundという警告が出ることがある。これはOpenSSLのライブラリがプロジェクト内に不足しているためで、XCode7でOpenSSLを使用する場合は、CocoaPodsからOpenSSLをダウンロードして使用すると良い。

CocoaPodsのインストール

  • まずは、Xcodeバージョン管理ツールの1つであるCocoaPodsをMacにインストールする。

gemのアップデート

sudo gem update --system

CocoaPodsのインストール

sudo gem install cocoapods
    ERROR:  While executing gem ... (Errno::EPERM)
        Operation not permitted - /usr/bin/xcodeproj
  • そこで、インストールフォルダを/usr/local/binに変更してインストールする
sudo gem install -n /usr/local/bin cocoapods

CocoaPodsのセットアップ

pod setup

以上で、XCodeプロジェクト管理ツールCocoaPodsのインストールが完了する。

OpenSSLのインストール

CocoaPodsはPodfileと呼ばれる設定ファイルに、インストールの内容を設定することでインストールを実行することが可能である。XCodeでSSLを使用するには、CocoaPodsからOpenSSL-Classicをインストールする。

プロジェクトファイルに移動

cd PROJECT_DIRECTORY

Podfileを作成

source 'https://github.com/CocoaPods/Specs.git'
pod 'OpenSSL-Classic', '1.0.1.j'

OpenSSLライブラリをインストール

pod install
  • ここで当該のXcode Projectを開いていると以下のように警告されるので、Xcodeは閉じてからインストールする
[!] Please close any current Xcode sessions and use `XXXXX.xcworkspace` for this project from now on.

CocoaPodsからライブラリをインストールするとXXXXX.xcworkspaceというファイルが作成されるので、XXXXX.xcodeprojではなくXXXXX.xcworkspaceをクリックして起動する。また、ターゲットの設定で、HEADER_SEARCH_PATHSに$(inherited)を追加する。

AWS EC2(3)AMIとインスタンス

AMI

AMI(Amazon Machine Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、

  • OSやアプリケーションなどのルートボリュームのテンプレート
  • 起動を許可するAWSアカウント
  • インスタンスにアタッチするボリュームのマッピング

などの情報が含まれている。

AMIは、AWSや様々な組織が公開しており、これを利用することができる。特にAmazon Linuxは、AWSが提供しているRHEL系のAMIで、AWS CLI Amazon EC2 API 等がパッケージに含まれているため便利で使い勝手が良い。また、自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる

なお、AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。

リージョンをまたがるコピー

作成したAMIを別リージョンで使用する際は、AWS CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。自身のリージョン情報を取得するには、AWS CLIから以下のコマンドを入力する。

$ curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'

AMIの作成

既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。

$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
$ shred -u ~/.*history
$ history -c
$ exit

インスタンスからの Linux AMI の作成

ストレージ

ストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。

Instance Store

  • EC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる
  • インスタンス停止(STOP)することができない

instance store-backed のインスタンス

Elastic Block Store

  • ネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。
  • デフォルトでは、DeleteOnTermination フラグが true に設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。
  • スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。
  • インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。

Amazon EBS-backed インスタンス

容量と性能

汎用SSD(gp2)のパフォーマンスは、ボリュームサイズに比例する。つまり、小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。

各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理(バースト)は、このクレジットから消費されていく。一方、標準性能を下回るI/Oであった場合はクレジットに加算されていく。ただし、加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。なお、汎用SSD(gp2)は、

  • 容量が33.4GB以下であれば、標準性能100IOPS
  • 容量が1000GB以下であれば、3000IOPSのバースト性能を利用可能
  • 容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持

と定義されている。また、スループットは、170GB以下では128 MB/秒170GBを超えると160MB/秒である。

インスタンス

概要

  • EC2は、1500MTUに加えてジャンボフレームをサポートする。
  • ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。

インスタンスのライフサイクル

インスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。ただし、EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。

インスタンスのライフサイクル

インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。一方、インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う

インスタンスの公開鍵

EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。ただし、これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。

キーペアのインポート

インスタンスの時刻

デフォルトでは UTC(協定世界時間)時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。

vi /etc/rc.local
ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

インスタンスの復旧

ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。

また、AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。また、ネットワークや電源のメンテナンスが実施される場合もある。

インスタンスメタデータ

実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。

http://169.254.169.254/latest/meta-data/

AWS Cognito(5)スロットリング

スロットリングとは

AWSは各サービスにサービス制限(スロットリングを行っており、各アカウントごとに使えるリソースの上限が設定されている。例えば、EC2は初期状態では最大20台までしかインスタンスを起動できない設定となっている。フルマネージドのサービスに対してもこれらの制限が設定されており、「フルマネージド」という名称でありながら負荷に合わせて際限なくスケールするわけではない。また、サービスによっては、サービス制限一覧にこの上限値が明記されていないものもある。

上限値以上にリソースを使用する場合はサポートプランに加入の上、サポートに必要なリソース数とその理由を付けて上限値の引き上げや撤廃を申請する必要がある。上限値の変更が必要な理由が不明確であったり必要以上のリソースを要求すると、要望が叶えられないこともあるので注意が必要である。理由を明確にした上で申請する必要がある。

なお基本的にAWSのマネージドサービスは、「定常的な利用」や「一時的なサービスを簡単に作成するため」に提供するシステムであるという考え方のようで、バースト的なアクセスや複雑な処理、定常的に大きな負荷が掛かる処理については、EC2上にシステムを構築して利用すべきであるというのがAmazonの方針のようである。大きな負荷の掛かる処理の場合は、上限引き上げ申請するだけでなく、EC2を用いて実現できないかについても検討すべきであろう。

Cognitoのスロットリング

AWSのサービスは日々拡張されていっているので、スロットリングの値は随時変更されている可能性がある。その前提のもと現時点で、

  • Cognito Identity: 数百/毎秒程度
  • Cognito Sync : 数千/毎秒程度

でスロットリングされており、それ以上の負荷が掛かる可能性があったりそれ以上のリソースを必要とする場合は、サポートに上限引き上げの申請を行う必要があるようだ。また、申請を行ったとしても標準値の数倍程度までしか拡張できないようである。Cognitoは昨年の9月に東京リージョンにきたばかりのサービスであるので、用意されているリソースにも限りがあるのかもしれない。今後のリソース拡張に期待したい。

AWS EC2(2)使用する上で注意すること

EC2は、AWSマネージメントコンソールからクリック1つでインスタンスを起動できる、非常に便利なクラウドサービスである。一方でとても簡単に利用できることから、全ての制限が取っ払われ、自分の思い通りのまま自由にリソースを使用できるサービスだというような錯覚に陥りがちだ。EC2も元を辿ればデータセンターの中にある物理マシンである。使用する際にはいくつかの注意すべき点が存在する。

サービスで使用する際にT2インスタンスは使わない

T2インスタンスは、AWSの公式説明によると「ベースラインを超えてバーストする能力がある CPU パフォーマンスのベースラインを提供する、バーストパフォーマンスインスタンスです」とある。しかし実際は、データセンター内の同一物理サーバ上に収納されている他のインスタンスが実験用途等で使用され、バースト上の負荷がそのインスタンスに掛かった場合は、自分のインスタンスにも影響が出る可能性がある。したがって商用サービス等の安定した運用が求められる利用方法の場合にT2インスタンスを使用することはおすすめしない。

バックアップを用意しよう

インスタンスが落ちたり、リージョンごとサービスダウンする可能性もゼロではない。24時間365日稼動しているように見えるクラウドサービスにもダウンタイムは確実に存在する。少なくともアベイラビリティゾーンを分ける、可能であれば他のリージョンにもバックアップを取るなどの障害対策はしておこう。

古いインスタンスは使わない

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。古くなれば電源やHDDなどが故障するリスクも高まる。実際にハードウェアに異常が起こり、EC2のインスタンスが急に応答しない、インスタンスが落ちるなどの現象が発生することがあるようだ。したがって、古いインスタンスはなるべく使わず、M3を使うぐらいならM4を、C3を使うくらいならC4を使おう。ちなみにインスタンスが落ちた場合、Auto Recovery機能をONにしていれば、自動で再起動してくるようである。

リソースは枯渇する

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。用意しているリソース量が全て使用されればリソースは枯渇する。実際に東京リージョンでは、年末年始などの多くの企業がイベント利用を行うシーズンに、特定のインスタンスタイプが起動できないことがあるようだ。またリソースの枯渇だけでなく、メンテナンスが原因で新たなリソースが確保できないということもあり得る。どうしてもリソースの確保が必要であれば事前に確保しておき、実際に使用するまでインスタンスをStopしておくなどの対応が必要である。リザーブドインスタンスの利用も検討したい。

バージニアリージョンは諸刃の剣

バージニアリージョンは、AWS創業の地。新しいサービスが一番に投入されるリージョンでもあり、リソース量も他のリージョンと桁違いに大きい。しかし一方で施設の老朽化が進んでいるからか異常なほどサービスダウンが多い。日本でEC2を使ったサービスを展開をする際に、わざわざバージニアリージョンを使用するメリットはあまり無いが、リソース量が大きいためバックアップリージョンとして利用する価値はあるだろう。レイテンシーを気にするのであれば、リソース量は劣るが物理距離が近い、シンガポール等のアジアパシフィック地域のリージョンも候補に入れたい。

上限引き上げはお早めに

AWSのサービスには、それぞれサービス制限(スロットリング)が適用されており、例えば、EC2は初期状態では最大20台までしかインスタンスを起動できない設定となっている。上限値以上にリソースを使用する場合はサポートプランに加入の上、サポートに必要なリソース数とその理由を付けて上限値の引き上げや撤廃を申請する必要があるが、上限値の変更が必要な理由が不明確であったり必要以上のリソースを要求すると断られる場合もあるので、少なくとも処理に3営業日以上掛かることを見越して、早めに上限引き上げを申請しておいたほうがよいだろう。

Auto Scaleは過信しない

Auto Scaleはリソース量に合わせてインスタンス量を自動で調整してくれるとても便利なサービスである。しかし、閾値を超えたことを検知して新たなインスタンスを立ち上げるまで数分を要する。したがってバースト的な負荷には対応できない。瞬間的なアクセスが予想されるのであれば、Auto Scaleは使わずにあらかじめ手動で、一定数のインスタンスを立ち上げておこう。

CPU使用率が定常的に30%を超えるのであれば代替策を考えよう

CPU使用率が定常的に30%を超えるのであればもう1つ上のインスタンスに変更するか、同じインスタンスをもう1つ用意しよう。

性能の良いインスタンスで台数少なく運用する方がラク

どのような処理をするかにもよるが、低い性能のインスタンスを大量に並べるよりかは、性能の良いインスタンスを台数少なく並べたほうが運用がラクなことが多い。場合によるけどさ。

EBSのボリュームサイズによってI/O性能は変化する

ディスク容量あまり使わないからと最小限のディスク容量しか確保していない状態で、大量のディスクアクセスが発生した場合は皆が悲しむことになる。汎用(SSD) ボリュームのパフォーマンスはボリュームサイズによって変化するように設計されており、ボリュームサイズが大きければ大きいほど、良いI/O性能が与えられる。一定量のディスクアクセスが発生する可能性がある場合は、1TBなど大きめのボリュームサイズを割り当てておくほうがよい。

とりあえずCPU利用率を見ていればOK

CloudWatchはいろいろな項目があるので、どの項目を確認すればEC2が正常であるのか判断に困るかもしれない。そんなときは取り敢えずはCPU使用率だけでも見ておこう。

そのほかに注意すること

  • インスタンスを停止状態から実行状態に移行するたびに 1 時間分のインスタンス時間が課金される。
  • インスタンス起動後に設定変更できない項目が存在する。VPCやサブネット、Roleなどは後から変更できない。Roleは使う予定がなくても取り敢えず作成しておいたほうが良い。(参考:EC2起動後に、後からできること・できないこと

Fluentd + Elastichsearch + Kibana(1)CentOS7で環境構築する

Fluentdで収集したログをElastichsearch + Kibanaに入れて可視化する。ここを参考にしながら、まずはCentOS7に環境構築してみる。

Elastichsearch

OpenJDKのインストール

Elasticsearchは、インストールにJAVA7以降(Java8 Update 20以降、もしくはJava7 Update 55以降)のJDKを必要とする。Oracle JavaもしくはOpen JDKがサポートされているようなので、今回はOpenJDK8をインストールする。

sudo yum -y install java-1.8.0-openjdk

Elastichsearch のインストール

RPMからElastichsearchをインストールする。

sudo rpm -ivh https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.3.5/elasticsearch-2.3.5.rpm

インストールが終わると以下のように忠告されるので、

### NOT starting on installation, please execute the following statements to configure elasticsearch service to start automatically using systemd
 sudo systemctl daemon-reload
 sudo systemctl enable elasticsearch.service
### You can start elasticsearch service by executing
 sudo systemctl start elasticsearch.service

言われた通りにコマンドを実行し、Elastichsearchを起動。

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

Fluentd

Fluentdをインストール

自動インストールスクリプトが用意されているので、これを実行する。現在、Fluentdは2.X系で開発が進められているので、td-agent2を指定してインストールを行う。

sudo curl -L http://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh

FluentdとElastichsearchとの連携

FluentdからElastichsearchへデータを受け渡すためのプラグインをインストールする。

sudo yum -y install gcc libcurl-devel
sudo td-agent-gem install fluent-plugin-elasticsearch

Fluentdを起動

sudo systemctl enable td-agent
sudo systemctl start td-agent

Kibana

Kibanaのインストール

Elastichsearchのリポジトリを追加する。

sudo vi /etc/yum.repos.d/elastic.repo

[kibana-4.4]
name=Kibana repository for 4.4.x packages
baseurl=http://packages.elastic.co/kibana/4.4/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

yumからインストールする。

sudo yum install kibana -y

Kibanaを起動

sudo systemctl enable kibana
sudo systemctl start kibana

Kibanaを起動

これでインストール作業が全て完了。
インストールしたサーバの5601ポートにアクセスするとこんなページが見れるはず。

http://XXX.XXX.XXX.XXX:5601

Kibana