I'm Sei.

現在、運用で使用しているちょこっとした CloudFormation テンプレートがあるのですが、Terraform に置き換えるとどんな感じになるか試してみました。

以下、現在使っている CloudFormation のテンプレートです。

{ "AWSTemplateFormatVersion" : "2010-09-09", "Parameters" : { "ImageId" : { "Type" : "String", "MinLength" : "12", "MaxLength" : "12", "AllowedPattern" : "ami-[a-zA-Z0-9]*" }, "InstanceType" : { "Default" : "t2.micro", "Type" : "String", "AllowedValues" : [ "t2.micro", "t2.small", "t2.medium", "m3.medium", "m3.large", "m3.xlarge", "m3.2xlarge", "c3.large", "c3.xlarge", "c3.2xlarge", "c3.4xlarge", "c3.8xlarge", "g2.2xlarge", "r3.large", "r3.xlarge", "r3.2xlarge", "r3.4xlarge", "r3.8xlarge", "i2.xlarge", "i2.2xlarge", "i2.4xlarge", "i2.8xlarge", "hs1.8xlarge" ] }, "KeyName" : { "Type" : "String", "MinLength" : "1", "MaxLength" : "64" }, "SecurityGroup" : { "Type" : "String", "MinLength" : "1", "MaxLength" : "64" }, "LoadBalancer" : { "Type" : "String", "MinLength" : "1", "MaxLength" : "64" }, "Desired" : { "Default" : "1", "Type" : "Number", "MinValue" : "1" }, "Min" : { "Default" : "1", "Type" : "Number", "MinValue" : "1" }, "Max" : { "Default" : "1", "Type" : "Number", "MinValue" : "1" } }, "Resources" : { "LaunchConfiguration" : { "Type" : "AWS::AutoScaling::LaunchConfiguration", "Properties" : { "ImageId" : { "Ref" : "ImageId" }, "InstanceType" : { "Ref" : "InstanceType" }, "InstanceMonitoring" : "true", "KeyName" : { "Ref" : "KeyName" }, "SecurityGroups" : [ { "Ref" : "SecurityGroup" } ] } }, "AutoScalingGroup" : { "Type" : "AWS::AutoScaling::AutoScalingGroup", "Properties" : { "AvailabilityZones" : { "Fn::GetAZs" : "" }, "Cooldown" : "300", "DesiredCapacity" : { "Ref" : "Desired" }, "HealthCheckGracePeriod" : "300", "LaunchConfigurationName" : { "Ref" : "LaunchConfiguration" }, "LoadBalancerNames" : [ { "Ref" : "LoadBalancer" } ], "MaxSize" : { "Ref" : "Max" }, "MinSize" : { "Ref" : "Min" } } }, "IncreaseGroupSize" : { "Type" : "AWS::AutoScaling::ScalingPolicy", "Properties" : { "AdjustmentType" : "ChangeInCapacity", "AutoScalingGroupName" : { "Ref" : "AutoScalingGroup" }, "Cooldown" : "60", "ScalingAdjustment" : "1" } }, "DecreaseGroupSize" : { "Type" : "AWS::AutoScaling::ScalingPolicy", "Properties" : { "AdjustmentType" : "ChangeInCapacity", "AutoScalingGroupName" : { "Ref" : "AutoScalingGroup" }, "Cooldown" : "60", "ScalingAdjustment" : "-1" } }, "CPUAlarmHigh" : { "Type" : "AWS::CloudWatch::Alarm", "Properties" : { "AlarmActions" : [ { "Ref" : "IncreaseGroupSize" } ], "ComparisonOperator" : "GreaterThanThreshold", "Dimensions" : [ { "Name" : "AutoScalingGroupName", "Value" : { "Ref" : "AutoScalingGroup" } } ], "EvaluationPeriods" : "1", "MetricName" : "CPUUtilization", "Namespace" : "AWS/EC2", "Period" : "60", "Statistic" : "Average", "Threshold" : "70" } }, "CPUAlarmLow" : { "Type" : "AWS::CloudWatch::Alarm", "Properties" : { "AlarmActions" : [ { "Ref" : "DecreaseGroupSize" } ], "ComparisonOperator" : "LessThanThreshold", "Dimensions" : [ { "Name" : "AutoScalingGroupName", "Value" : { "Ref" : "AutoScalingGroup" } } ], "EvaluationPeriods" : "2", "MetricName" : "CPUUtilization", "Namespace" : "AWS/EC2", "Period" : "300", "Statistic" : "Average", "Threshold" : "20" } } } }

Launch Configuration と Auto Scaling Group を作成しつつ、それに付随する CloudWatch の Alarm と Scaling Policy をくっつけているだけのシンプルなものです。

パラメータとしては、Launch Configuration のベースになる AMI の ID やインスタンスタイプ、Auto Scaling Group のベースになる ELB 名などがあります。

これを Terraform の設定ファイルにすると以下のようになります。

variable "aws_access_key" {} variable "aws_secret_key" {} variable "aws_region" { default = "ap-northeast-1" } variable "launch_configuration_name" {} variable "image_id" {} variable "instance_type" { default = "t2.micro" } variable "key_name" {} variable "security_group" {} variable "auto_scaling_group_name" {} variable "load_balancer" {} variable "desired" {} variable "min" {} variable "max" {} provider "aws" { access_key = ${var.aws_access_key} secret_key = ${var.aws_secret_key} region = ${var.aws_region} } resource "aws_launch_configuration" "default" { name = ${var.launch_configuration_name} image_id = ${var.image_id} instance_type = ${var.instance_type} key_name = ${var.key_name} security_groups = [${var.security_group}] } resource "aws_autoscaling_group" "default" { name = ${var.auto_scaling_group_name} availability_zones = ["ap-northeast-1a", "ap-northeast-1c"] health_check_grace_period = 300 load_balancers = [${var.load_balancer}] desired_capacity = ${var.desired} max_size = ${var.max} min_size = ${var.min} launch_configuration = ${aws_launch_configuration.default.name} }

短くなった！？

と思いきや、Terraform には Scaling Policy と CloudWatch の Alarm を作成するためのリソースがまだ用意されていないようで、そこの部分は記述していません。

また、CloudFormation には便利な関数がいくつか用意されていて、上のテンプレートでは Fn::GetAZs とかいう関数を使ってリージョン内で有効な AZ をリストアップしていましたが、Terraform では残念ながらベタ打ちです。

実行

実行してみます。

$ terraform apply -var-file=./terraform.tfvars

変数ファイルは terraform.tfvars というファイルに以下のように記述しています。

aws_access_key = "XXXXXXXXXXXXXXXXXXXXX" aws_secret_key = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" launch_configuration_name = "my-conf" image_id = "ami-XXXXXXXX" instance_type = "t2.micro" key_name = "sei" security_group = "my-sg" auto_scaling_group_name = "my-group" load_balancer = "my-lb" desired = 2 min = 1 max = 2

まだ IAM のサポートはないようで、Provider に aws を指定した場合は、アクセスキーとシークレットキーの指定が必須になります。

実行結果は以下のようになりました。

aws_launch_configuration.default: Creating... image_id: "" => "ami-XXXXXXXX" instance_type: "" => "t2.micro" key_name: "" => "sei" name: "" => "my-conf" security_groups.#: "" => "1" security_groups.0: "" => "my-sg" aws_launch_configuration.default: Creation complete aws_autoscaling_group.default: Creating... availability_zones.#: "" => "2" availability_zones.0: "" => "ap-northeast-1a" availability_zones.1: "" => "ap-northeast-1c" desired_capacity: "" => "2" health_check_grace_period: "" => "300" launch_configuration: "" => "my-conf" load_balancers.#: "" => "1" load_balancers.0: "" => "my-lb" max_size: "" => "2" min_size: "" => "1" name: "" => "my-group" aws_autoscaling_group.default: Creation complete Apply complete! Resources: 2 added, 0 changed, 0 destroyed. The state of your infrastructure has been saved to the path below. This state is required to modify and destroy your infrastructure, so keep it safe. To inspect the complete state use the `terraform show` command. State path: terraform.tfstate

上手くいったようです。

まさに Infrastructure as Code！という感じ。

削除

削除は以下のようにします。

$ terraform plan -destroy -out=./terraform.tfplan -var-file=./terraform.tfvars $ terraform apply ./terraform.tfplan aws_autoscaling_group.default: Destroying... aws_autoscaling_group.default: Error: ResourceInUse: You cannot delete an AutoScalingGroup while there are instances or pending Spot instance request(s) still in the group. Error applying plan: 1 error(s) occurred: * ResourceInUse: You cannot delete an AutoScalingGroup while there are instances or pending Spot instance request(s) still in the group. Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure.

しかし、AutoScaling 内にインスタンスが残っているから削除できないよ！という旨のメッセージが出て失敗してしまいます。

なぜ...

悲しいけど手動でコンソールから消しました。

補足

0.1.0 では aws_autoscaling_group リソースに ELB を指定するパラメータは用意されていませんが、Github 上の開発版ではほぼ実装されているように見えたので、ちょこっとソースをいじって使ってみたら上手くいきました。

すこし前までは Pocket と Instapaper のどちらもサポートしてくれているニュース系のアプリは多かったのですが、最近では Pocket しかサポートされてないアプリが目立ってきました。

Instapaper ユーザの自分としては悲しいです...

Pocket は iOS 向けの SDK が公式で提供されていて、簡単に連携機能を実装することができます。 https://github.com/Pocket/Pocket-ObjC-SDK

片や、Instapaper は公式 SDK とかないので、連携機能を実装するにはすこし手間がかかります。

簡単に Instapaper との連携を実装できる SDK があれば...！

というわけで、Swift の勉強がてら Instapaper SDK を書いてみました。 https://github.com/seei/instapaper-ios-sdk

以下、開発してみて目新しかったことなどをいくつか。

シングルトン

Pocket SDK に習ってシングルトンパターンで実装しています。 シングルトンの実装はこちらを参考に以下のように実装しました。

class InstapaperSimpleAPI: NSObject { class var sharedAPI: InstapaperSimpleAPI { struct Singleton { static let instance = InstapaperSimpleAPI() } return Singleton.instance } }

Optional 型のクロージャ

他の型と同じようにクロージャも Optional 型でラップすることができます。 以下のように if 文で nil チェックをすることなく非同期処理のコールバックを呼び出せたりします。

func login(username: String, password: String?, success: ((NSURLResponse!) -> Void)?, failure: ((NSError!) -> Void)?) { ... failure?(err) ... }

Type Alias

typealias キーワードで任意の型のエイリアスを宣言することができます。 typealias を使うと上の関数を以下のように書くことができるので、同じクロージャの型を頻繁に使う場合に便利です。

typealias SuccessHandler = (NSURLResponse!) -> Void typealias FailureHandler = (NSError!) -> Void func login(username: String, password: String?, success: SuccessHandler?, failure: FailureHandler?) { ... }

ちなみに、The Swift Programming Language では typealias をプロトコルと組み合わせて使うサンプルなどがあります。

非同期テスト

あと Swift ネタではありませんが、Xcode 6 で非同期テストをサポートしてくれる XCTestExpectation というクラスが登場しました。 expectationWithDescription: で expectation を作成して、waitForExpectationsWithTimeout: でタイムアウトを設定しておくと、fullfill が呼ばれるかタイムアウトまで wait してくれるようになります。

func testLogin() { let expectation = self.expectationWithDescription("logged in") InstapaperSimpleAPI.sharedAPI.login(username, password: password, success: { response in expectation.fulfill() }, failure: { error in XCTFail("\(error)") expectation.fulfill() }) self.waitForExpectationsWithTimeout(5, handler: nil) }

その他にも KVO や NSNotification をベースにしたテストも書けるようなのですが、ドキュメントが見つからないので WWDC のビデオでも見て勉強しようと思います。

終わりに

頑張ってライブラリ書きましたが、iOS 8 で新たに登場する App Extension が Instapaper からリリースされればすべて解決するのではないか？！

そうなったら今 Instapaper サポートしてないアプリからも使えるようになって嬉しいなぁ

iOS 7 では設定アプリの Privacy > Location Services から各アプリの位置情報のプライバシー設定ができました。

iOS 7 ではアプリに対して位置情報の使用を許可するか、許可しないかの 2 択しかありませんでしたが、iOS 8 では以下の 3 択に変わるようです。 - 許可しない (Never) - 使用中のみ許可 (WhenInUse) - 常に許可 (Always) WhenInUse は、「アプリまたはその機能が画面上に表示されている場合のみ位置情報を利用することを許可」する設定です。 Always は、「バックグラウンドで実行中の場合にもアプリが位置情報を利用することを許可する」する設定です。 WhenInUse か Always かによって、Core Location で使える機能が変わります。 また、同じ Core Location の機能を使っていてもユーザからの見え方が若干変わります。 ## Core Location の機能の制限 プライバシー設定に関わる Core Location の各機能との対応は以下のようになります。 | | Never | WhenInUse | Always | |:-|:-:|:-:|:-:| | 標準位置情報サービス (Standard Location Service) | | ✔ | ✔ | | 大型変更位置情報サービス (Significant-Change Location Service) | | | ✔ | | 地理的領域の観測 (Grographical Region Monitoring) | | | ✔ | | ビーコン領域の観測 (Beacon Region Monitoring) | | | ✔ | | ビーコンの距離測定 (Ranging) | | ✔ | ✔ | Standard Location Service を使って位置情報を取得したり、あるいは Ranging でビーコンとの距離測定をおこなうだけの場合には WhenInUse で足ります。 Significant-Change Location Service か Region Monitoring をおこなう場合には Always が必要になります。 冒頭でバックグランドで実行中のアプリが位置情報を取得するには Always が必要だと書きましたが、Standard Location Service にも Ranging にもバックグラウンドで更新を取得する機能がありますね。 なので、たとえば Standard Location Service でもバックグラウンドで位置情報を取得したい場合には、Always が必要な気もしますが、この場合でも WhenInUse でいいようです。 というのも、iOS 8 ではアプリがバックグラウンドで位置情報を使用している間は、ステータスバーが青くハイライトされるようになるので、「アプリまたはその機能が画面上に表示されている場合のみ位置情報を利用することを許可」するほうに入るというわけです。 デザリングしている最中は以下のようにステーテスバーが青くなりますが、これと同じような感じになります。

##ユーザからの見え方の違い 青いバーが出るのは WhenInUse を許可されたアプリがバックグラウンドで位置情報を使用しているときだけで、Always の場合は青くならないようです。 また、ステータスバーをタップすることで直近に起動したアプリを開くことができるようになります。 もう一つ変化があるのが、以下のような位置情報を利用するときに表示される確認ダイアログです。

iOS 7 でも Info.plist の NSLocationUsageDescription キーで、ダイアログに独自のメッセージを指定することができました。 ここにはアプリがどのような目的で位置情報を使用するのかを説明するテキストを指定するわけですが、iOS 8 ではこのテキストの指定が必須になります。 さらに、Always の場合は一度ユーザが許可をしても、数日毎に再び確認ダイアログが表示されるようになるようです。 ## 実装 実装の際には以下の 3 点に注意する必要があります。 - Info.plist 内の UsageDescription - 認証状態の取得 - 認証リクエスト用 API ### Info.plist 内の UsageDescription iOS 6 以降は Info.plist 内の NSLocationUsageDescription キーでダイアログに任意のメッセージを表示することができました。 iOS 8 では NSLocationUsageDescription は depricated になり、WhenInUse と Always の 2 タイプに合わせて以下の 2 つのキーが追加されます。 - NSLocationUsageDescription - **NSLocationWhenInUseDescription** - **NSLocationAlwaysUsageDescription** また、これまではオプショナルだったのが、iOS 8 では使用するタイプに対応するキーについては指定が必須になります。 ### 認証状態の取得 位置情報の認証状態を示す CLAuthorizationStatus については `kCLAuthorizationStatusAuthorized` が depricated になり、新しく `kCLAuthorizationStatusAuthorizedAlways` と `kCLAuthorizationStatusAuthorizedWhenInUse` が追加されます。 - kCLAuthorizationStatusNotDetermined - kCLAuthorizationStatusRestricted - kCLAuthorizationStatusDenied - kCLAuthorizationStatusAuthorized - **kCLAuthorizationStatusAuthorizedAlways** - **kCLAuthorizationStatusAuthorizedWhenInUse** ### 認証リクエスト用 API iOS 8 では CLLocationManager に新しく追加される認証リクエスト API を呼び出すことで、認証ダイアログが表示されるようになります。 - `requestAlwaysAuthorization` - `requestWhenInUseAuthorization` このメソッドは何度でも呼び出すことはできますが、ダイアログが表示されるのはステータスが NotDetermined の場合だけです。 したがって、一度ダイアログが表示されてユーザが許可する / しないの選択をした後は、このメソッドを呼び出しても何も起こりません。 ## iOS 7 をサポートする iOS 7 をサポートする場合は引き続き NSLocationUsageDescription や kCLAuthorizationStatusAuthorized を使用します。 また、認証リクエスト API を使用する場合にはメソッドが使用可能かをチェックしてから実行します。

if locationManager.respondsToSelector("requestWhenInUseAuthorization") { locationManager.requestWhenInUseAuthorization() }

デモコード

以下は iOS 7 / 8 両方サポートする場合の Swift で書いたデモコードです。

import UIKit class ViewController: UIViewController, CLLocationManagerDelegate { var locationManager: CLLocationManager! override func viewDidLoad() { super.viewDidLoad() if !locationManager { locationManager = CLLocationManager() } locationManager.delegate = self } @IBAction func startUpdates(sender: AnyObject) { locationManager.startUpdatingLocation() } func locationManager(manager: CLLocationManager!, didUpdateLocations locations: [CLLocation]!) { NSLog("didUpdatesLocations") } func locationManager(manager: CLLocationManager!, didFailWithError error: NSError!) { NSLog("didFailWithError: \(error)") } func locationManager(manager: CLLocationManager!, didChangeAuthorizationStatus status: CLAuthorizationStatus) { switch status { case .NotDetermined: if locationManager.respondsToSelector("requestWhenInUseAuthorization") { locationManager.requestWhenInUseAuthorization() } case .Restricted, .Denied: self.alertLocationServicesDisabled() case .Authorized, .AuthorizedWhenInUse: break default: break } } func alertLocationServicesDisabled() { let title = "Location Services Disabled" let message = "You must enable Location Services to track your run." if NSClassFromString("UIAlertController") { let alert = UIAlertController(title: title, message: message, preferredStyle: .Alert) alert.addAction(UIAlertAction(title: "Settings", style: .Default, handler: { action in let url = NSURL(string: UIApplicationOpenSettingsURLString) UIApplication.sharedApplication().openURL(url) })) alert.addAction(UIAlertAction(title: "Close", style: .Cancel, handler: nil)) presentViewController(alert, animated: true, completion: nil) } else { UIAlertView(title: title, message: message, delegate: nil, cancelButtonTitle: "Close").show() } } }

CLLocationManager オブジェクトにデリゲートオブジェクトを設定すると、初回に locationManager:didChangeAuthorizationStatus: が呼ばます。

そこで、まだプライバシー設定がされてない状態 (NotDetermined) の場合は、requestWhenInUseAuthorization メソッドで認証ダイアログを表示します。

位置情報が使用できない状態 (Restricted or Denied) の場合は、位置情報の使用を許可して欲しいという自前のダイアログを表示しています。 (話がそれますが、iOS 8 で復活した設定アプリへの URL スキームを使っています)

また、Swift の場合は CLAuthorizationStatus の値が以下になります。

NotDetermined

Restricted

Denied

Authorized

AuthorizedWhenInUse

Authorized については iOS 7 の場合はこれまでと同様の位置情報の使用が許可された状態、iOS 8 の場合は Always が許可された状態を示すようです。

参考

位置情報とマッププログラミングガイド - Apple Developer

HealthKit 入門 1 に引き続き HealthKit.framework に登場するクラスについてまとめていきます。 今回はデータ取得編です。

HKQuery

すべてのクエリ用のクラスは HKQuery を継承しています。 HKQuery オブジェクトは以下の 2 つのプロパティをもっています。

sampleType: HKSampleType?

predicate: NSPredicate?

sampleType はクエリの対象となるデータのデータタイプで、predicate はクエリの結果として返されるデータのフィルタリングのための NSPredicate オブジェクトです。 (NSPredicate についてはこちらの公式ドキュメントが詳しいです。)

さて、HKQuery のサブクラスには以下のメンツがいます。 順番に見ていきます。

HKSampleQuery

HKObserverQuery

HKAnchoredObjectQuery

HKStatisticsQuery

HKStatisticsCollectionQuery

HKSampleQuery

HKSample オブジェクトをクエリするためのクラスです。 HKSampleQuery オブジェクトは sampleType と predicate に加えて以下の 2 つのプロパティをもちます。

limit: Int

sortDescriptors: AnyObject[]?

limit にはクエリの結果として返されるオブジェクトの個数を指定します。 制限なしで欲しい場合には 0 を指定します。

sortDescriptors には返されるオブジェクトのソート順を NSDiscriptor オブジェクトの配列で指定します。

試しに前回の記事で HealthKit に保存した体温 36 ℃ の HKQuantitySample オブジェクトを取得してみます。

let healthStore: HKHealthStore = HKHealthStore() let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) let endDate: NSSortDescriptor = NSSortDescriptor(key: HKSampleSortIdentifierEndDate, ascending: false) let sampleQuery: HKSampleQuery = HKSampleQuery(sampleType: tempType, predicate: nil, limit: 0, sortDescriptors: [endDate], resultsHandler: { (query: HKSampleQuery!, results: AnyObject[]!, error: NSError!) in NSLog("\(results?[0])") // -> 36 degC }) healthStore.executeQuery(sampleQuery)

tempType という名前で体温のデータタイプをあらわす HKQuantityType オブジェクトを作成しています。

つぎに、HKQuantity オブジェクトの endDate プロパティの降順で結果を取得するために NSDiscriptor オブジェクトを作成しています。

最後に、HKSampleQuery コンストラクタでクエリオブジェクトを作り、HKHealthStore オブジェクトの executeQuery(query: HKQuery?) メソッドを使ってクエリを実行しています。

HKObserverQuery

HKObserverQuery は HealthKit のデータベースの変更を検知するためのクラスです。 HKObserverQuery オブジェクトにハンドラを登録しておくと、データベースにデータが追加されたり削除されたりしたタイミングでそのハンドラを呼んでくれるようになります。

たとえば、常に最新の体温をビュー表示しておく機能を作りたいとします。 最新の体温データは他の計測デバイスから随時データベースに保存されています。

HKObserverQuery オブジェクト作成時に登録するハンドラ内で HKSampleQuery を実行するようにすれば、データベース上の体温データに変更があった場合のみクエリが実行されるようになります。

こうしておけば、数秒毎にクエリを実行してデータが更新されているかをチェックしたりする必要がなくなります。

以下のサンプルコードでは、体温データの変更を検知する HKObserverQuery オブジェクトを実行し、そのハンドラ内で最新の体温データを取得しています。

let healthStore: HKHealthStore = HKHealthStore() let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) let endDate: NSSortDescriptor = NSSortDescriptor(key: HKSampleSortIdentifierEndDate, ascending: false) let sampleQuery: HKSampleQuery = HKSampleQuery(sampleType: tempType, predicate: nil, limit: 0, sortDescriptors: [endDate], resultsHandler: { (query: HKSampleQuery!, results: AnyObject[]!, error: NSError!) in NSLog("\(results?[0])") }) let observerQuery: HKObserverQuery = HKObserverQuery(sampleType: tempType, predicate: nil, updateHandler: { (query: HKObserverQuery!, completionHandler: HKObserverQueryCompletionHandler!, error: NSError!) in healthStore.executeQuery(sampleQuery) }) healthStore.executeQuery(observerQuery)

HKAnchoredObjectQuery

HKAnchoredObjectQuery も HKObserverQuery と同様に、アプリ上のデータと HealthKit のデータベースとの同期をとるためのクエリです。

たとえば、その日の摂取カロリーのデータをリスト形式でリアルタイムに表示したいとします。 ユーザがアプリを起動すると、アプリは HealthKit からその日の摂取カロリーのデータのリストを取得します。

このリストは取得した時点では最新ですが、ユーザがアプリを楽しんでいるうちに新しいデータが他のアプリから HealthKit のデータベースに追加されている可能性があります。

ここで HKAnchoredObjectQuery を使うと、自分のアプリ側のデータとデータベース側のデータとの差分だけを取得することができます。

差分の取得には Anchor と呼ばれる Int 値を使います。

HealthKit 上のデータには保存された順に Anchor が連番で振られていて、クエリ作成時にこの番号を指定することで、指定した番号よりも大きな Anchor をもつデータだけを取得することができます。

以下は HKAnchoredObjectQuery の使用例です。

let healthStore: HKHealthStore = HKHealthStore() let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) var lastAnchor: Int = 0 let observerQuery = HKObserverQuery(sampleType: tempType, predicate: nil, updateHandler: { (query: HKObserverQuery!, completionHandler: HKObserverQueryCompletionHandler!, error: NSError!) in let anchoredObjectQuery = HKAnchoredObjectQuery(type: tempType, predicate: nil, anchor: lastAnchor, limit: 0, completionHandler: { (query: HKAnchoredObjectQuery!, results: AnyObject[]!, newAnchor: Int, error: NSError!) in NSLog("lastAnchor: \(lastAnchor), newAnchor: \(newAnchor), results.count: \(results.count)") lastAnchor = newAnchor }) healthStore.executeQuery(anchoredObjectQuery) }) healthStore.executeQuery(observerQuery)

先ほどと同様に HKObserverQuery のハンドラ内でクエリを実行しています。

Anchor の初期値は 0 にしています。 HKObserverQuery 内のハンドラはクエリ実行時に 1 度呼ばれるので、0 にしておくことですべてのデータを取得することができます。

また、ハンドラの引数に新しい Anchor 値が渡されるので lastAnchor にその値を再代入しています。 次にハンドラが呼ばれるときには新しい Anchor が使用されるので、新しく追加されたデータだけが取得できます。

HKStatisticsQuery & HKStatistics

HKStatisticsQuery と HKStatitics はともに統計データを取得するためのクラスです。 HKStatisticsQuery は HKQuantityType のみをクエリの対象にします。

クエリ作成時に以下のオプションの中から取得したい統計値を指定します。 これらのオブションはビットフラグとして用意されているので、複数のオプションを同時に指定することができます。

HKStatisticsOptions.DiscreteAverage

HKStatisticsOptions.DiscreteMin

HKStatisticsOptions.DiscreteMax

HKStatisticsOptions.CumulativeSum

上から順番に、平均値、最小値、最大値、合計値です。

すべての HKQuantityType オブジェクトは Discrete か Cumulative のどちらかに分類されていて、Discrete なオプションと Cumulative なオプションを同時に指定することはできません。

Discrete に分類されるのは身長や体重や血圧などで、平均値、最小値、最大値をサポートしています。 Cumulative は歩数や摂取カロリーなどで、こちらは合計値をサポートしています。

クエリを実行すると HKStatistics オブジェクトがハンドラに渡されます。

以下は今日の体温の最小値と最大値を取得するサンプルコードです。

let healthStore: HKHealthStore = HKHealthStore() let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) let cal: NSCalendar = NSCalendar.currentCalendar() let comps: NSDateComponents = cal.components((NSCalendarUnit.CalendarUnitYear | NSCalendarUnit.CalendarUnitMonth | NSCalendarUnit.CalendarUnitDay), fromDate: NSDate()) let startDate: NSDate = cal.dateFromComponents(comps) let endDate: NSDate = cal.dateByAddingUnit(NSCalendarUnit.CalendarUnitDay, value: 1, toDate: startDate, options: nil) let today: NSPredicate = HKQuery.predicateForSamplesWithStartDate(startDate, endDate: endDate, options: HKQueryOptions.StrictStartDate) let statsOptions: HKStatisticsOptions = (HKStatisticsOptions.DiscreteMin | HKStatisticsOptions.DiscreteMax) let statsQuery = HKStatisticsQuery(quantityType: tempType, quantitySamplePredicate: today, options: statsOptions, completionHandler: { (query: HKStatisticsQuery!, result: HKStatistics!, error: NSError!) in NSLog("Min: \(result.minimumQuantity()), Max: \(result.maximumQuantity())") }) healthStore.executeQuery(statsQuery)

HKQuery クラスには NSPredicate の便利なコンストラクタが用意されていて、それを使って today という NSPredicate オブジェクトを作成しています。 これで startDate プロパティが今日になっているデータにフィルタリングしています。

また、statsOptions で最小値と最大値を取得するためのビットフラグをたてています。

クエリを実行するとハンドラに HKStatistics オブジェクトが渡されるので、最小値と最大値をそれぞれ出力しています。

HKStatisticsOptions.SeparateBySource

先ほどは触れませんでしたが、HKStatisticsOptions にはもう一つ SeparateBySource というフラグがあります。

HealthKit 上の個々のデータにはそれぞれソース (情報元) があるわけですが、このフラグを使用することでソース別に統計値を取得することができるようになります。

たとえば、歩数をカウントしてくれるデバイスを同時に 2 つ身につけているとします。 それぞれのデバイスが HealthKit に歩数を書き込んでいくと、そのままでは合計値が実際の 2 倍になってしまいます。

これでは困るので、クエリを実行する際に SeparateBySource を立てて、ソース別に統計値を取得するようにします。

以下のサンプルコードでは、先ほどの statsQuery から返ってくる HKStatistics オブジェクトから、自分のアプリから登録された体温データのみを対象に算出された最小値と最大値を取得しています。

let statsQuery = HKStatisticsQuery(quantityType: tempType, quantitySamplePredicate: today, options: statsOptions, completionHandler: { (query: HKStatisticsQuery!, result: HKStatistics!, error: NSError!) in var defaultSource: HKSource = HKSource.defaultSource() NSLog("Min: \(result.minimumQuantityForSource(defaultSource)), Max: \(result.maximumQuantityForSource(defaultSource))") })

以上、HealthKit のデータベースからデータを取得するためのクラスを簡単にまとめてみました。

あとは HKStatisticsCollectionQuery という HKStatistics をまとめて取得できるクエリが WWDC で紹介されてたりしましたが、まだ不明な部分が多いです。

その他にも HealthKit.framework のヘッダファイル群を見ていると色々と面白そうなクラスがあったりするので、また気がノッたらまとめてみようと思います。

参考

Introducing HealthKit

HealthKit.framework に登場する主なクラスを簡単にまとめていきます。 そして HealthKit についてなんとなくわかった気になります。

HKUnit

体重をあらわす単位はアメリカではポンド (lb) が広く使われているようですが、日本ではキログラム (kg) が広く使われています。 体温をあらわす単位は日本では摂氏が広く使われていますが、華氏が使われているところもあったりします。

HealthKit では HKUnit クラスを使って様々な単位をあらわすことができます。

キログラムとポンドをあらわすオブジェクトをそれぞれ作ってみます。

let kgUnit: HKUnit = HKUnit(fromString: "kg") let lbUnit: HKUnit = HKUnit(fromString: "lb")

もうすこし複雑な単位をつくることもできます。 たとえば、1 デシリットル当たりのグラムを作るには以下のようにします。

let gPerdLUnit: HKUnit = HKUnit(fromString: "g/dL")

また、基本単位については独自のメソッドが用意されていて、グラム等は以下のようにして作ることもできます。

let gUnit: HKUnit = HKUnit.gramUnit()

HKQuantity

単位が作れれば今度は「じゃあ一体何グラムなんだ？」となりますが、これに応えてくれるのが HKQuantity クラスです。 HKQuantity オブジェクトはプロパティに数値とその単位 (HKUnit オブジェクト) をもつことになります。

試しに 18g をあらわす HKQuantity オブジェクトを作ってみます。

let gUnit: HKUnit = HKUnit.gramUnit() let grams: HKQuantity = HKQuantity(unit: gUnit, doubleValue: 18)

コンストラクタには HKUnit オブジェクトと Double 値を指定します。

grams から値を取り出すには doubleValueForUnit(unit: HKUnit?) -> CDouble を使います。 grams からキログラムでの値を取得してみます。

let kgUnit: HKUnit = HKUnit(fromString: "kg") let kgrams: CDouble = grams.doubleValueForUnit(kgUnit) // -> 0.018

また、当然ながら単位は互いに変換可能なものとそうでないものがあります。 doubleValueForUnit(unit: HKUnit?) -> CDouble に変換できない単位を指定した場合には例外がとびます。

isCompatibleWithUnit(unit: HKUnit?) -> Bool を使うと、オブジェクトがもっている数値が指定する単位に変換可能かを Bool 値で取得することができます。

let kgCompatible = grams.isCompatibleWithUnit(HKUnit(fromString: "kg")) // -> true let gPerdLCompatible = grams.isCompatibleWithUnit(HKUnit(fromString: "g/dL")) // -> false

HKObjectType

18g が作れれば今度は「何が 18g なの？」となります。 糖分の摂取量かもしれませんし、食物繊維の摂取量かもしれません。 これに応えてくれるのが HKObjectType クラスです。

HealthKit に保存されるデータは必ずそのデータがどういう種類のデータなのかという情報をもちます。 体重とか身長とか、体脂肪率とか、栄養素の摂取量とかいろいろあります。

そして、このデータの種類自体もいつくかのカテゴリーに分かれており、それぞれサブクラスが用意されています。 HKObjectType 以下のクラスヒエラルキーは以下のようになってます。

HKCharasteristicType

ユーザ固有の情報をあらわすデータタイプ (血液型や生年月日など)

HKSampleType

ある特定のタイミングに計測された量をあらわすデータタイプ (血圧や歩数など)

HKQuantityType

ある特定のタイミングに計測されたカテゴリーをあらわすデータタイプ (睡眠の状態など)

さて、ここからがちょっとややこしいのですが、HKObjectType クラスは上の 3 つサブクラスに対応する形で以下の 3 つのコンストラクタをもっています。

charastetisticTypeForIdentifier(identifier: String?) -> HKQuantityType!

quantityTypeForIdentifier(identifier: String?) -> HKQuantityType!

categoryTypeForIdentifier(identifier: String?) -> HKQuantityType!

一方で、HealthKit で扱える約 60 種類のデータタイプはそれぞれ固有の ID が用意されています。 たとえば、心拍数には HKQuantityTypeIdentifierHeartRate、体温には HKQuantityTypeIdentifierBodyTemperature という ID がそれぞれ振られています。

この ID を上のコンストラクタの引数にしてデータタイプのインスタンスを作ります。

各 ID の前半部は上の 3 つのサブクラス名のどれがか付いていて、HKQuantityTypeIdentifier~ という ID が付いているものは、quantityTypeForIdentifier(identifier: String?) -> HKQuantityType! にしか渡せません。 作りたいデータタイプの ID にあわせてコンストラクタを選んであげる必要があります。

たとえば、体温の HKQuantityType オブジェクトを作るには以下のようにします。

let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature)

HKObject

HealthKit 上には、値とその単位とデータタイプ + 付加情報をもったオブジェクトを単一のデータとして保存します。 このオブジェクトは HKObject クラスを継承したクラスのインスタンスになります。

HKObject クラス以下のクラスヒエラルキーは下のようになっています。

HKQuantitySample

HKQuantitySample オブジェクトのプロパティをもっています。 (適当に 変数名: Class名 という形式で書いています。)

quantityType: HKQuantityType

quantity: HKQuantity

HKQuantityType オブジェクトには扱える単位がそれぞれ決まっていて、これが quantity プロパティのもつ単位とミスマッチを起こすと例外がとびます。

HKCategorySample

HKCategorySample オブジェクトは以下プロパティをもっています。

categoryType: HKCategoryType

value: Int

HKCategoryType オブジェクトには扱える値が enum で定義されていて、value プロパティにはその範囲内の値を指定してあげる必要があります。

HKSample

HKSample オブジェクトは以下のプロパティをもっています。

startDate: NSDate

endDate: NSDate

startDate と endDate にはそのデータが計測された時刻がはいります。 たとえば、歩数であればカウントを始めた時刻と終えた時刻がそれぞれはいります。 体重など計測を始める時刻と終える時刻が同じ時刻になるような場合には、startDate と endDate には同じ時刻がはいります。

HKObject

HKObject オブジェクトは以下プロパティをもっています。

UUID: NSUUID

source: HKSource

metadata: Dictionary

source には、データがどのアプリから提供されたものかという情報が自動ではいります。 metadata には、体温のデータがどの部位で計測されたものなのかとかそういう類のメタデータがはいります。

さて、ここまできてようやく HealthKit に保存できるデータを作成することができるようになりました。

試しに体温のデータを作ってみます。

let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) let myTemp: HKQuantity = HKQuantity(unit: HKUnit.degreeCelsiusUnit(), doubleValue: 36.0) let tempSample: HKQuantitySample = HKQuantitySample(type: tempType, quantity: myTemp, startDate: NSDate(), endDate: NSDate()) NSLog("\(tempSample.quantity)") // -> 36 degC

まず HKQuantityTypeIdentifierBodyTemperature という体温の ID を使って tempType という名前の HKQuantityType オブジェクトを作成しています。 つぎに、36.0 という値を摂氏温度としてもつ myTemp という HKQuantity オブジェクトを作成しています。

最後に、コンストラクタに tempType と myTemp、それから startDate と endDate に現在時刻を指定して HKQuantitySample オブジェクトを作成しています。

では、このデータを HealthKit に保存してみます。

HealthStore

HealthStore クラスは HealthKit 上のデータベースとの仲介役を果たしてくれます。 データの保存や取得は HealthStore オブジェクトのメソッド使って実行することになります。

先ほど作成した tempSample を保存してみます。

let store: HKHealthStore = HKHealthStore() store.saveObject(tempSample, withCompletion: { (success: Bool, error: NSError!) in if success { NSLog("Saved!") } })

しかし、このままでは保存に失敗してしまいます。

HealthKit 上のデータは、アプリごとに、さらにデータタイプごとに書き込みと読み出しのパーミッションを設定することができます。 この設定は Health アプリを通じてユーザがおこないます。

デフォルトではすべてのデータタイプについて書き込みと読み出しの権限がありませんので、保存や取得をおこないたいデータタイプについての許可をユーザに求める必要があります。

いまは体温の保存しようとしていますので、体温のデータタイプの保存と取得の許可を求めてみます。

let healthStore: HKHealthStore = HKHealthStore() let tempType: HKQuantityType = HKObjectType.quantityTypeForIdentifier(HKQuantityTypeIdentifierBodyTemperature) let dataTypes: NSSet = NSSet(object: tempType) healthStore.requestAuthorizationToShareTypes(dataTypes, readTypes: dataTypes, completion: { (success: Bool, error: NSError!) in if success { NSLog("Authorized!") } })

欲しいデータタイプを NSSet 型で作成しています。 dataTypes に複数のデータタイプを含めることで、複数のデータタイプについてまとめて許可を求めることもできます。

また、特定のデータタイプについてのパーミッションをチェックしたい場合は以下のようにします。

var status: HKAuthorizationStatus = healthStore.authorizationStatusForType(tempType) NSLog("\(status == HKAuthorizationStatus.SharingAuthorized)") // -> true

これでやっとこさ HealthKit 上にデータを保存することができました。

つぎにやりたいのはデータの取得です。

が、ちょっと長くなりそうなので、以上をデータ生成 & 保存編として区切りまして、データ取得編は別にまとめようと思います。

参考

Introducing HealthKit

CloudFront のアクセスログを S3 に出力するように設定していると、日に日に大量のログファイルが溜まっていきます。

中には 1 MB 程度のファイルもあれば、数百 bytes 程度の小さなものもあります。

何にせよ、とにかく大量にあります。

小さいファイルはまとめる

CloudFront のログのように小さいファイルが大量にあるようなケースは Hadoop が苦手とするパターンで、そのまま扱うと大抵めちゃんこ時間がかかります。

そういう場合は、S3DistCp という便利ツールを使って S3 上のログファイルをもうすこし大きいサイズに連結して、HDFS にコピーするとパフォーマンスがあがることがあります。

ちなみに、EMR のベストプラクティスによると、Gzip で圧縮されている場合は 1 ~ 2GB、LZO で圧縮されている場合は 2 ~ 4GB が最適なファイルサイズらしいです。

S3DistCp の使用例

S3DistCp を使うと S3 上のログデータをファイル名によってフィルタリングしたり、グルーピングしたり、圧縮フォーマットを変更したりできます。

以下 SSH でマスターノードにログインして、ホームディレクトリから実行する例をあげていきます。

また、S3 に上がっているログは CloudFront のログで Gzip 圧縮されている前提です。

圧縮なし & 1 時間ごとにグルーピング & フィルタリングなし

hadoop jar lib/emr-s3distcp-1.0.jar \ --src s3://logs.example.com/cf/ \ --dest hdfs://`hostname -f`:9000/data/ \ --groupBy '.*ABCDEFG1234567.([0-9]+-[0-9]+-[0-9]+-[0-9]+).*' \ --targetSize 2048 \ --outputCodec none

CloudFront のログは {distribution-ID}.{YYYY}-{MM}-{DD}-{HH}.{unique-ID}.gz みたいな規則で命名されています。

なので、--groupBy で上のようにグルーピングを指定することで、1 時間ごとに連結されたファイルが生成されます。

--targetSize は MB 単位で指定します。

--groupBy で連結されたファイルが --targetSize を超えた場合は、複数ファイルに分割されます。

--outputCodec は圧縮フォーマットを指定します。ここでは圧縮しない設定として none を指定しています。

各オプションの詳細、その他のオプションについてはこちら。

Gzip 圧縮 & 1 時間ごとにグルーピング & フィルタリングなし

hadoop jar lib/emr-s3distcp-1.0.jar \ --src s3://logs.example.com/cf/ \ --dest hdfs://`hostname -f`:9000/data/ \ --groupBy '.*ABCDEFG1234567.([0-9]+-[0-9]+-[0-9]+-[0-9]+).*(\.gz)' \ --targetSize 2048

--outputCodec を省略するとコピー元と同様の圧縮フォーマットでコピーしてくれます。

CloudFront のログは Gzip 圧縮されているので、生成されるファイルを Gzip で圧縮したい場合は --outputCodec を省略します。

ここで --outputCodec に gzip を指定すると、2 重圧縮されたファイルが生成されてしまうという悲しい状態になってしまいます。 (ドキュメントをちゃんと読んでいなかったせいでここでかなりハマりました...)

また、ここで --outputCodec を省略すると、生成されるファイルは Gzip ファイルにもかかわらず gz 拡張子をつけてくれません。

これでは Hive 等からロードする場合、Gzip ファイルとして認識してくれません。

したがって、--groupBy オプションの指定を上のようにすることで、生成されるファイル名の末尾に .gz とつくようにしています。

Gzip 圧縮 & 1 日ごとにグルーピング & フィルタリング指定なし

hadoop jar lib/emr-s3distcp-1.0.jar \ --src s3://logs.example.com/cf/ \ --dest hdfs://`hostname -f`:9000/data/ \ --groupBy '.*ABCDEFG1234567.([0-9]+-[0-9]+-[0-9]+)-[0-9]+.*(\.gz)' \ --targetSize 2048

--groupBy の指定をすこし変えて 1 日ごとにグルーピングするようにしています。

ファイルサイズが小さく、対象とする日付の範囲も広いような場合には 1 日単位でまとめちゃってもいいかもしれません。

Gzip 圧縮 & 1 日ごとにグルーピング & 日付指定 (2014-05-19 ~ 2014-05-20) でフィルタリング

hadoop jar lib/emr-s3distcp-1.0.jar \ --src s3://logs.example.com/cf/ \ --dest hdfs://`hostname -f`:9000/data/ \ --srcPattern '.*ABCDEFG1234567.2014-05-(19|20)-[0-9]+.*' \ --groupBy '.*ABCDEFG1234567.([0-9]+-[0-9]+-[0-9]+)-[0-9]+.*(\.gz)' \ --targetSize 2048

--srcPattern を指定することでマッチするファイル名だけにフィルタリングすることができます。

特定の日時の範囲に絞ることが許されるのであれば、こういうフィルタリングをしておくといいかもしれません。

LZO 圧縮について

通常、ソース側が非圧縮状態であれば --outputCodec で lzo と指定することで LZO で圧縮されるようになります。

ただ、ソース側が Gzip 圧縮されている状態で LZO 圧縮するように指定すると、二重圧縮されるようになってしまいます。

これは S3DistCp のバグのようで、次回の AMI のリリースにあわせて修正されていると嬉しいなぁという感じです。

先日 Vagrant 1.6 がリリースされました。

1.6 からプロバイダとして新たに Docker が追加されたので、Node.js を動かして Hello World してみました。

OS X ユーザ & ディレクトリの構成は以下のようになっている想定で進みます。

|-- docker | `-- Vagrantfile |-- Dockerfile |-- index.js `-- Vagrantfile

Vagrantfile が 2 つありますが ./docker/Vagrantfile のほうは Docker コンテナのホストマシン (VM) 用の Vagrantfile になります。

まず ./Vagrantfile は以下のように記述しています。

# -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| config.vm.network "forwarded_port", guest: 8080, host: 8080 config.vm.provider "docker" do |d| d.vagrant_vagrantfile = "./docker/Vagrantfile" d.build_dir = "." end end

Docker をプロバイダとして使う指定があり、その中で d.vagrant_vagrantfile と d.build_dir を指定しています。

d.vagrant_vagrantfile で Vagrantfile へのパスを指定することで、Docker コンテナのホストマシンの環境を好きに構築できるようになります。

この指定が省略された場合は、boot2docker のボックスを元に環境が構築されます。

d.build_dir では Dockerfile へのパスを指定します。

d.build_dir の代わりに d.image で Docker イメージを指定することも可能です。

あと、ポートフォワードの設定ですが、こちらはローカル (ここでは OS X) と VM の間ではなく、Docker コンテナのホスト (VM) と Docker コンテナの間のポートマッピングの設定になります。

つぎに ./docker/Vagrantfile は以下のように記述しています。

# -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| config.vm.box = "mitchellh/boot2docker" config.vm.provider "virtualbox" do |v| v.customize ["modifyvm", :id, "--natpf1", "tcp-port8080,tcp,,8080,,8080"] v.check_guest_additions = false v.functional_vboxsf = false end config.nfs.functional = false end

こちらは d.vagrant_vagrantfile が省略された場合にデフォルトで使用されるこちらの Vagrantfile を元にしています。

今回は、加えてローカル (ここでは OS X) と VM の間のポートフォワードの設定をしています。

そして ./Dockerfile は以下のような感じにしています。

FROM dockerfile/nodejs RUN mkdir /app WORKDIR /app ADD . /app CMD ["node", "index.js"] EXPOSE 8080

Node.js 入りの Docker イメージを使って index.js を起動しています。

./index.js の中身は以下の様な感じ。

require('http').createServer(function(req, res) { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.end('Hello World!\n'); }).listen(8080);

単純に Hello World! を返すだけのスクリプトです。

あとは vagrant up するだけです。

$ vagrant up --provider=docker $ curl http://localhost:8080 Hello World!

Docker ベースなので vagrant destroy からの vagrant up とかがかなり速いです。

これまで、ElastiCache (Redis) のバックアップをとりたいときは、EC2 上の Redis を ElastiCache のスレーブにして rdb ファイル等を取得する方法しかありませんでした。

まどろっこしくて、早く直接バックアップがとれるような機能がほしいなぁと思っていたのですが、とうとう実装されたようです！

現在はバックアップ/リストア等の操作は cache.m1.small 以上でしかできないようです。

自動スナップショットの設定

日毎に自動でバックアップを作成する設定ができます。

新規クラスタに設定する

通常通り Launch Cache Cluster からクラスタの作成を進めていくと、以下のような画面に進みます。

ここで Enable AutoMatic Backups で Yes を選ぶといろいろ設定できるようになります。

Backup Retention Period は「自動で作成されるスナップショットをどのくらいの期間残しておくか？」の設定です。

Snapshot window は「この時間帯であればスナップショットをとってもいいよ」という時間帯の設定です。

設定した時間帯を過ぎると、バックアップが作成されていることが確認できました！ 自動スナップショットの場合は Snapshot Type が automated になっているようです。

スナップショットの作成は、内部的には Redis の BGSAVE コマンドが実行されているらしいです。

BGSAVE コマンドで、子プロセスを spawn して RDB ファイルの生成を行うようになっていますが、子プロセスを spawn する数秒間は読み書きができなくなるらしいので、Snapshot window は慎重に指定する必要がありそうです。

また、スナップショット作成中はパフォーマンスが落ちる可能性があるので、もし可能であれば Primary からスナップショットをとるのではなく、Read Replica を作成した上でそこからスナップショットを作成するようにしたほうがよさそうです。

既存のクラスタに設定する

既存のクラスタに自動スナップショットを設定する場合は、クラスタ一覧の Modify ボタンから設定できるようになっています。

手動でスナップショットを作成

手動でもスナップショットがとれます。

Snapshots メニューに移動して、Create Snapshot を押すと以下のようなダイアログが出てくるので、スナップショットを作成したいクラスタを選択して、名前をつけて Yes, Create！

完了すると Snapshot Type が manual となっているスナップショットが作成されています。

手動でのスナップショット作成は、自動スナップショットと違って自動で削除されることがないので、長期間に渡ってスナップショットを保持しておきたい場合には、手動で作成することになります。

また、スナップショットを選択して Copy Snapshot を押すことで、自動スナップショットで作成されたスナップショットから手動スナップショットを作成することもできます。

スナップショットからのリストア

スナップショットからクラスタを立ち上げることができます。

スナップショットの一覧から目的のスナップショットを選択し、Restore Snapshot ボタンを押します。

すると、以下のようなダイアログが立ち上がるので、名前をつけて Launch Cache Cluster！

半年くらい前に Chef をいじっていた頃、「Vagrant は、Chef のレシピ開発時にローカルマシンでトライ & エラーが手早くできて便利だな」くらいにしか思っていませんでした。

そこからあんまり Vagrant 触ってなかったのですが、なんかの拍子に Vagrant のトップページを見て、本来は開発環境の構築を手助けするツールであることに今更ながら気がつきました。。

簡単に言うと、

「開発に参加する人が各自ローカルマシンに環境を構築するのはいろいろ大変ですよね？」 「設定ファイル 1 つ置いといて、vagrant up コマンドを実行するだけで開発環境がソッコーで構築できますよ！」

というのが Vagrant の魅力なわけで、Chef のレシピ開発にとどまらずいろんなことができるのです。(ドヤ)

これまで

適当な シングルページ Web アプリケーションを複数人で開発するような場合を思い浮かべてみます。

たとえば、サーバサイドでは Node.js や MongoDB や Redis が使われていて、一方のクライアントサイドの開発では Grunt なんかが使われているとします。 (弊社ではよくあるパターン)

こういう状況で、クライアントサイドの開発者がローカルマシンでサーバサイドとのつなぎ込み部分の開発をしたいとなると、MongoDB や Redis などという得体の知れないものを諸々インストールしないと動きません。

この程度であれば Readme がちゃんと書かれていたら意外と問題ないかもしれません。

でも、もっとシステムが複雑になり、必要なミドルウェアが増えるにつれて、「インストールが失敗するんだけど...」とか「自分のマシンで動かなくなったんだけど...」みたいなことが起こるようになります。

その度にクライアントサイドの開発はストップします。サーバサイドの開発者が環境構築をサポートするために、サーバサイドの開発もストップするかもしれません。

Vagrant を使うと

Vagrant を使うようになると開発に参加する人は、Vagrantfile が用意されたプロジェクトのリポジトリをクローンして vagrant up を実行するだけで環境が整います。

Vagrantfile というのが Vagrant の設定ファイルです。

Vagrantfile で共有ファイルシステムの設定がされていれば Sublime Text 2 で開発できますし、ネットワークの設定が適切にされていれば Chrome の Developer Tools も使えます。

Vagrant を使うことでこれまで使っていたエディタやブラウザが使えなくなるわけではありません。

これは、嬉しいですね。

ようするに、vagrant up だけ覚えていれば、ほかに覚えることはほとんどありません。

ただし、それができるにはプロビジョニングの設定も含めて、誰かの手によって Vagrantfile がメンテされている必要があります。

プロビジョニングについて

プロビジョニングというのは、上のケースで言うと Node や MongoDB、Redis、Grunt など、開発に必要な環境を構築するということです。

Vagrant はシェルスクリプト、Chef、Puppet 等によるプロビジョニングが標準でサポートされています。

vagrant up がコケずに環境が構築できるのであれば、ぶっちゃけどれ使ってもいいと思います。

自分の好きなのを使えばいいと思うし、別にプロジェクトごとに違っていてもいいと思います。

もっと言うと、1 つの Vagrantfile 内で複数のプロビジョナを使うこともできるので、それでもいいと思います。

vagrant up がコケない AND 必要な環境がちゃんと揃うようになっていれば無問題です。

誰がプロビジョニングの設定をするべき？

ネットワークの設定や共有ファイルの設定は、そう頻繁に変わることはないでしょう。

ただ、プロビジョニングの設定は、プロジェクトの進行中でも追加の設定が必要になったりすると思います。

たとえば、上のケースで言うと、Grunt よりもやっぱり Middleman のほうが向いていそうなのでそっちを使いたい、といったことはままあると思います。

しかし、Middleman を使うには Ruby の環境が必要なので、プロビジョニングの設定を追加する必要があります。

では Ruby のプロビジョニングの設定はだれがするべきか？

理想をいえば、Middleman を使いたいその人がプロビジョニングの設定までできれば最高です。

「Middleman なり Jekyll なり好きな開発ツールを使ってもいいよ、ただし、みんなが困らないようにプロビジョニングの設定もしておいてね」というのが開発チーム内で実践できれば最高です。

もちろんサーバサイドの言語やミドルウェアについても同じです。

といっても難しい場合もあると思うので、そのときは得意な人に頼むというのができればそれでもいいでしょう。

Rails 環境構築のサンプル

ここまでダラダラいろんなことを書きましたが、実際に使ってみないとわからん！っていう人のためにサンプルを用意しました。

Git と VirtualBox と Vagrant の環境が整っていれば以下の手順で、Ruby on Rails の開発環境が構築できるかと思います。

$ git clone https://github.com/seei/vagrant-rails.git $ vagrant up

初回は、ボックスという Vagrant が仮想マシンを構築する際につかうベースイメージをダウンロードするのに時間がかかりますが、次回以降はさくっと終わると思います。

あとは Readme.md 通りに Vagrant にログインして、Rails のサーバを起動したら、手元のブラウザで http://localhost:8080 にアクセスしてみましょう。

以下の様なページが表示されたら成功です。

Highrise と連携する社内向けのシステムを koa で構築してて、勉強がてら node-highrise-api という Highrise 向けのライブラリをベースに co-highrise というのを書いてみました。

uniba/co-highrise

AngularJS ネタです。

たとえばディレクティブを作成する際に、isolate scope を作成しつつ親スコープのモデルとの双方向バインディングを作りたいときは “=“ を使用すると思います。

以下の例ではうまく動きます。 親スコープの name もディレクティブのスコープの name も共に fuga となります。

myApp.directive('myd', function() { return { restrict: 'E', template: '<div>{{name}}</div>', scope: { name: '=' }, link: function(scope, el, attrs) { scope.name = 'fuga'; } } });

しかし、以下のようにタイムアウトのコールバック内で同様の処理をするとうまく動きません。

myApp.directive('myd', function() { return { restrict: 'E', template: '<div>{{name}}</div>', scope: { name: '=' }, link: function(scope, el, attrs) { setTimeout(function() { scope.name = 'fuga'; }, 1000); } } });

setTimeout だけでなく、各種ユーザイベントの待ち受けや Ajax リクエストなどの非同期処理のコールバックで同じことが起きます。

そこでコールバックを scope.$apply() でラップしてやることで Angular は値の更新を知ることができるようになり、期待通りに動くようになります。 (このへんの話題については AngularJS and scope.$apply という記事が参考になります。)

myApp.directive('myd', function() { return { restrict: 'E', template: '<div>{{name}}</div>', scope: { name: '=' }, link: function(scope, el, attrs) { setTimeout(function() { scope.$apply(function() { scope.name = 'fuga'; }); }, 1000); } } });

ちなみに、以下のように書いても期待通りに動きます。

myApp.directive('myd', function() { return { restrict: 'E', template: '<div>{{name}}</div>', scope: { name: '=' }, link: function(scope, el, attrs) { setTimeout(function() { scope.name = 'fuga'; scope.$apply(); }, 1000); } } });

クライアントサイド MV* フレームワークは久しく Backbone.js を使ってきましたが、近頃 AngularJS をちょくちょくいじったりしています。(ミーハーなんで...)

個人的にはやはり $scope オブジェクトによる 2-way データバインディングが一番グッとくるポイントです。

説明するまでもないかもしれませんが、2-way データバインディングとは、モデルの変更は自動的に DOM に反映される、逆にユーザの操作による DOM の変更は自動的にモデルに反映されるというやつです。

イメージとしては以下のような感じでしょうか。

DOM からの変更もモデルからの変更も、もう片方に自動で反映されるので 2-way ですね。

Firebase とは

そして Firebase というのはいわゆる BaaS 系のサービスで、AngularJS 向けに AngularFire というプラグインが提供されています。

そして AngularFire から $firebase というカスタム Service が使えるようになっています。

この $firebase が、AngularJS のモデルの変更は自動的に Firebase 上のデータに反映され、Firebase 上のデータに変更があれば AngularJS のモデルに反映される、という処理を担ってくれます。

イメージ図は以下のような感じです。

ようするに、AngularJS のモデルと Firebase 上のデータの間の 2-way データバインディングです。

したがって AngularJS と Firebase と組み合わせることで DOM からデータの永続化の部分までのデータバインディングを簡単に作れちゃいます。

以下サンプルコード。

サンプルコード

<html ng-app="sampleApp"> <head> <title>3-way Data Binding Example</title> <!-- Firebase --> <script src="//cdn.firebase.com/v0/firebase.js"></script> <!-- AngularJS --> <script src="//ajax.googleapis.com/ajax/libs/angularjs/1.2.11/angular.min.js"></script> <!-- AngularFire Plugin --> <script src="//cdn.firebase.com/libs/angularfire/0.6.0/angularfire.min.js"></script> <!-- The code for a simple messaging service is below --> <script> angular.module('sampleApp', ['firebase']) .controller('SampleController', ['$scope', '$firebase', function($scope, $firebase) { var ref = new Firebase('https://sample-fire-1616.firebaseio.com/text'); $firebase(ref).$bind($scope, 'text'); }]); </script> </head> <body ng-controller="SampleController"> <input type="text" ng-model="text"/> <h1>You said: {{text}}</h1> </body> </html>

Firebase のコンストラクタには、個別の Firebase アプリケーションの URL を指定しておきます。 (Firebase にサインアップすると、自動で 1 つ作成されてメールで教えてくれます)

そして $firebase が返してくれるオブジェクトの $bind メソッドで text という Angular モデルとのデータバインディングを作っています。

実際に動かすとこんな感じです。

1 文字 1 文字がリアルタイムに双方のクライアントに反映されます。

たったこれだけのコードで、リアルタイムでコラボレーティブなアプリケーションが作れちゃいました... 簡単すぎる...

〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ロードバランサー編) 〜

今回、ロードバランサーは全面的に AWS の Elastic Load Balancing (ELB) を使用しました。

Web API を提供するシステムにはもともと ELB を使う予定だったのですが、静的ファイルの配信などは ClouldFront + S3 という構成でいこうと思っていました。

が、最終的には静的ファイルを配信するシステムも ELB + EC2 という構成になりました。

そのへんの経緯とか、AWS を使うときのシステムのフロント周りの負荷分散にはどういう選択肢があるのかとか、軽くまとめてみようと思います。

静的ファイルの配信には CloudFront を使ったほうがいいのか

CloudFront は S3 と併用することで、静的なファイルの配信のことはほとんど考えなくていい、というくらい簡単にファイル配信の仕組みが構築できます。

しかし、想定するリクエスト数や転送量によっては、他の方法でファイル配信システムを構築したほうがよいことがあります。 とくに大規模なトラフィックが想定される場合には、一度 AWS のサポートセンターに相談してみることをおすすめします。

今回は、1.3 MB ほどのすこし大きめの単一のファイルに、秒間 10,000 リクエストが押し寄せてきても耐えられるシステムを構築する必要がありました。 転送量にして 104 Gbps です。

そこで、サポートセンターに相談したところ、CloudFront を使うのではなく以下の 2 つのいずれかの方法をとることを勧められました。

S3 に異なる名前の同一のファイルを複数置いてランダムアクセスさせる

EC2 インスタンスを複数台立ち上げておいて ELB でアクセスを分散させる

S3 に異なる名前の同一のファイルを複数置いてランダムアクセスさせる

これは、S3 に同じファイルを多数置いておき、クライアント側からアクセスが各ファイルに分散するようにしてあげるという方法です。 こうすることでファイル 1 つだけの場合よりも S3 のパフォーマンスをあげることができます。

パーティショニングをうまく使う

S3 バケット内のオブジェクト達は、負荷分散のため、オブジェクト名をもとに物理的に離れたサーバにパーティショニングされて配置されるようになっています。

このような仕組みの上では、たとえば 1 つのオブジェクトへのアクセスが急激に上昇した場合、そのオブジェクトが配置されている単一のパーティションのみがアクセスをうけることになります。

なので、異なる名前の同一のファイルを多数用意して S3 に置いておき、クライアントからランダムアクセスしてあげるようにすることで、各パーティションにアクセスを分散させることができ、パフォーマンスを上げることができます。 (より効果的なオブジェクト名のつけ方については、Amazon S3のパフォーマンスをあげるコツ が参考になります。)

どのくらいの数のファイルを用意すればいいのか

で、実際にどのくらいのファイル数を用意すればよいのかということについてですが、Amazon S3のパフォーマンスをあげるコツ を見たりするに、各ファイルへのリクエストが 50 ~ 100 req/s くらいに収まるくらいの数を用意するのがいいのかなと思います。

今回は、先ほども触れた 1.3 MB の単一のファイルを配信するシステムで、10,000 req/s を捌く必要がありました。

というわけで、サポートセンターからも各ファイル 50 req/s くらいになるように 200 ファイル程置いたらいいよ、というアドバイスをうけたりしました。

今回はクライアントサイドの都合でランダムアクセスが難しかったのでこの方法がとれませんでしたが、特定のファイルにアクセスが集中するような場合には有効な方法だと思います。

EC2 インスタンスを複数台立ち上げておいて ELB でアクセスを分散させる

こちらは静的ファイル配信用の EC2 インスタンスを多数立ち上げておいて、ELB でバランシングさせる方法で、今回はこっちでやりました。 Auto Scaling Group などを使うことでインスタンスの管理も比較的簡単です。

ELB の Pre-warming 申請

ただし、急激なトラフィック増加が想定される場合には、事前に ELB の Pre-warming 申請をしておく必要があります。

「急激なトラフィック増加」とはどのくらいの増加なのか、ということですが、「5 ~ 10 分で 20% 以上のトラフィック増加」というのが目安らしいです。 (Pre-warming 申請とは何ぞや？という人は、同時大量アクセスに備えて ELB を Pre-wariming 状態にしておく を参照)

なので、それと同程度かそれ以上の増加率が想定される場合には、Pre-warming 申請をしておくと安心できます。

Pre-warming 状態の ELB でも対応できない場合

ただし、想定するリクエスト数や転送量によっては、Pre-warming 状態でも 1 つの ELB で対応できるトラフィックを超えている場合があります。

その場合は、Pre-warming 状態の ELB を複数用意し、DNS ラウンドロビンを設定しておくという方法があります。 これも Route 53 を使うことで簡単に設定できます。 (設定手順は、Pre-warming した複数の ELB を Route 53 で DNS ラウンドロビンする にまとめました。)

今回は、1.3 MB 程度の単一のファイルを配信するためのシステムが ELB 1 つで対応できる転送量を超えているということで、この方法をとりました。

Pre-warming 状態の 1 つの ELB に対するトラフィックが、HTTP リクエスト数にして 200,000 req/s、転送量にして 40 Gbps 程度に収まるようにということで、ヴァージニア、オレゴン、アイルランドの各リージョンに分散させて配置しました。

ちなみに、Web API を提供するシステムは、HTTP リクエスト 30,000 req/s、転送量 120 Mbps の想定だったので、Pre-warming 状態の ELB 1 つで問題ありませんでした。

とここまで書いといてなんですが、実際にどの方法をとるかを決める際には、AWS のサポートセンターに相談してみるのがいいかと思います。

自分も AWS のサポートセンターにいろいろ助けてもらったおかげで、お正月は笑って過ごすことができました。

Pre-warming 状態の ELB でも、想定するトラフィック等によっては 1 つでは対応しきれないことがあります！ (Pre-warming については 大量同時アクセスに備えて ELB を Pre-warming 状態にしておく を参照)

そういう場合は、Route 53 で DNS ラウンドロビンを設定して、複数の ELB にトラフィックを分散させるようにしておきます。

手順はそれほど難しくないのですが、忘れそうなので公開メモっておきます。

rr-sample.uniba.jp というホストに 2 つ ELB をもたせたいという気持ちでいきます！

まずは、ELB を作ります。

つぎに、Route 53 にうつり、ELB の数だけ A レコードを作成します。

Alias の Yes を選択することで、ターゲットが入力できるようになります。 フォーカスをあわせると、S3 のバケットや ELB などの候補がいくつか表示されるので、先ほど作成した ELB を選択します。

Routing Policy は Weighted を選択します。

Weight に入力する数値は、各 ELB + バックエンド EC2 のセットの性能が同じであれば、同じ数値を入力しておけば問題ないでしょう。 今回は、適当に 100 と入力しておきます。

Set ID は、Name と Type の組み合わせ内でユニークになっていればいいそうなので、ELB の名前とか入力しておけばいいでしょう。

そこから下の設定は DNS フェイルオーバーとかを設定するための項目だった気がするのですが、忘れちゃいました...

作成し終わったら、以下のような見た目になります。

dig ってみましょ〜

$ dig rr-sample.uniba.jp @ns-612.awsdns-12.net ;; ANSWER SECTION: rr-sample.uniba.jp. 60 IN A 176.34.31.155 $ dig rr-sample.uniba.jp @ns-612.awsdns-12.net ;; ANSWER SECTION: rr-sample.uniba.jp. 60 IN A 54.248.124.27

〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ログ収集編) 〜

今回は、大晦日のイベント用に EC2 インスタンスを複数台立ち上げておいて、年が明けたタイミングで全て Terminate してしまう予定でした。

ただ、Terminate した際に、そのままログも一緒に消えてしまうと何かあったときに困るので、Nginx のログやアプリケーションのログの収集に Fluentd を使い、とりあえず S3 にぶっ込んでおくことにしました。

Fluend は標準では 1 つの CPU コアしか使ってくれないので、複数の CPU コアをもっているサーバで動かす際は、マルチプロセス化することで CPU を効率的に使えるようになります。

具体的には、ログ集約用のサーバは in_multiprocess プラグインで複数のポートから受信できるようにしつつ、送信側は out_forward プラグインをつかって受信側でログを待ち受けている複数ポートへロードバランスするという構成になります。

送信側

送信側の設定はこんな感じになります。

# /etc/td-agent/td-agent.conf <match nginx.**> type forward buffer_queue_limit 8m buffer_chunk_limit 128 flush_interval 1s <server> host 192.168.1.3 port 24224 weight 60 </server> <server> host 192.168.1.3 port 24225 weight 60 </server> </match> ...

これで、指定したホストの 24224 番と 24225 番にラウンドロビンしてくれるようになります。

設定は、Fluentd out_forward における最適化パラメータいくつかの話 に習って、とりあえず以下の 3 つのパラメータに気をつけました。

flush_interval

buffer chunk が flush される間隔を設定するパラメータで、デフォルトは 60s です。 これがデフォルトのままだと、マルチプロセスで待ち受けている受信側から見ると、60 秒分のログを一つのプロセスが処理しないといけないということになります。 なので、60s のままでは受信側の負荷が偏りやすくなる、ということで 1s に設定しました。

buffer_chunk_limit

buffer chunk の最大サイズを指定するパラメータで、デフォルトは 8m になっています。 buffer chunk のサイズが buffer_chunk_limit に達するか、もしくは flush_interval を経過した時点で、新しい空の buffer chunk が作成されようになっているようです。

buffer_queue_limit

buffer chunk の転送に失敗した場合、その buffer chunk は送信側の queue に積まれ、再送信を試みる仕組みになっていて、このパラメータでその queue の長さを指定できます。 デフォルトでは 64 になっています。 queue の長さがこの buffer_queue_limit に達すると、新しい書き込みができなくなり、ログがロストすることになります。

buffer_chunk_limit とあわせて考えると、buffer_type が memory になっている場合、buffer_chunk_limit * buffer_queue_limit がサーバのメモリサイズを超えないようにしておかないといけません。

逆に buffer_chunk_limit * buffer_queue があまりに小さすぎると、今度は急なアクセス増加で受信側が耐えられなくなった際に、転送に失敗した buffer chunk が queue に大量に積まれしまい、ログがロストしてしまうという事態になります。

受信側

受信側は in_multiprocess プラグインを使ってこんな感じになります。

# /etc/td-agent/td-agent.conf <source> type multiprocess <process> cmdline -c /etc/td-agent/td-agent-child1.conf </process> <process> cmdline -c /etc/td-agent/td-agent-child2.conf </process> </source>

in_multiprocess プラグインは td-agent に標準搭載されていないので、別途インストールする必要があります。 インストール方法は、公式ドキュメント参照。

1 つの process セクションにつき 1 つ子プロセスが生成されるようになっています。 また、各 process セクション内で子プロセスの設定ファイルを指定しています。

子プロセス側の設定ファイルはこんな感じです。

# /etc/td-agent/td-agent-child1.conf <source> type forward port 24224 </source> include /etc/td-agent/td-agent-common.conf

ここでは、子プロセスごとに別のポートで待ち受ける設定にしておきます。 また、S3 にログを保存する設定は include を使って共通のものを読み込むようにしておきました。

# /etc/td-agent/td-agent-common.conf <match nginx.**> type s3 aws_key_id YOUR_AWS_KEY_ID aws_sec_key YOUR_AWS_SECRET/KEY s3_bucket YOUR_S3_BUCKET_NAME ... </match> ...

これで、送る側は 24224 と 24225 ポートにラウンドロビンでログを送信し、受ける側は 2 つ子プロセスが立ち上がっていて、それぞれ 24224 ポートと 24225 ポートで待ち受けるという構成ができました！

〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (負荷テスト編) 〜

ピーク時に秒間 1 万ユーザからのアクセスを想定する場合、画像や CSS、JavaScript 等のアセットを配信するためのシステムともなると、想定するべき HTTP リクエスト数はその数倍とか数十倍に膨れあがります。

となると、負荷テストの際にもそれと同程度か、あるいはそれ以上のリクエストをシュミレートする必要がでてくるので、負荷をかける側もそれなりに準備をしなくてはいけません。

結論からいうと、いつもお世話になっている Developers.IO の以下の記事から、JMeter クラスタを簡単に構築してくれる CloudFormation のテンプレートを拝借して使っていました。

お手軽JMeterクラスター 〜 fullbok編｜アドカレ2013 : CFn #1

構築手順などは記事のなかで詳しく解説されているので、実際に使う際には上の記事を参考にするのがよいかと思います。

というわけで、ここで書くこともあんまりないのですが、他に試したツールとか、つぎはこうしてみたいなぁというのをダラダラと書いてみたいと思います。

最初は httperf や wrk を使ってテストをやっていた

最初は、httperf や wrk など CLI で簡単に使えるツールを使って、AWS の t1.micro 1 台立ち上げて細々と負荷をかけていました。

負荷テスト素人だった頃は、「ヒューレット・パッカード製だし、httperf 使っていれば問題ないっしょ」って思ってましたが、実際に負荷を何度かかけてみると、負荷をかける側のスペックがボトルネックになって、t1.micro 1 台では到底カバーできないことに気が付きました。

じゃ、複数台たててやるか、ということでインスタンスを複数台たてて、ログインして、httperf を実行して、結果を手作業で集計する、というのをチマチマやっていました。

しかし、何度かやるうちに、結果を手集計するのがさすがに面倒になり、集計用のプログラムを自分で書くのもノリ気がしなかったので、他のツールを探してみることにしました。

つぎに Bees With Machine Guns というツールを試してみた

そんななか、Bees With Machine Guns というツールを見つけて試してみたりしました。

Bees With Machine Guns は、Python 製のコマンドラインツールで、負荷テスト用の AWS の t1.micro インスタンスをコマンド一発で好きな台数だけ立ち上げたり、落としたりができます。

また、立ち上げた Bees (t1.micro インスタンス達) にコマンド一発で ab (Apache Bench) を使った負荷テストを実行させることができます。

と、ここまでは AWS のコマンドラインツールと Capistrano なんかを使ってでも簡単にできそうですが、Bees With Machine Guns のいいところは Bees が実行した ab の結果を集計してくれるところです。

これで、手作業で集計したり、自分で集計用のプログラムを書く必要がなくなってだいぶハッピーになりました。

しかし、次第に「Cookie を使った一連のユーザーフローを再現したい」とか「HTML から読まれる CSS や画像等のリソースに対しても同時に負荷をかけたい」とか、新しい欲望が湧き出てきて、ab ベースの Bees With Machine Guns ではもの足りなくなってきました。

最終的に JMeter クラスタを使った負荷テストに落ち着いた

どうしたもんかと悩んでいたところに、冒頭でも紹介した JMeter クラスタ構築用の ClouldFormation のテンプレートを発見しました。

JMeter は GUI の負荷テストツールで、サーバから与えられた Cookie を保持してくれたり、ブラウザから辿ったページからロードされる画像や CSS へのリクエストも含めたテストプランが簡単に作成できたりと、やりたいことができそうでした。

かつ、JMeter を 1 台で使うのではなく、Master/Slave 構成にすることで、負荷をかける側のスペックもコントロールできる。

そんな構成が、CloudFormation でポチポチするだけで構築できる。

最高っす！ 手軽さと、 機能と性能を兼ね備えている！

というわけで、その後はそのテンプレートにお世話になりっぱなしでした。

Cookie の設定などはこの記事を参考にさせていただきました。

また、HTML からロードされる画像や CSS へのリクエストも含めたテストプランの作成方法は、長くなりそうだったので別の記事にしました。 JMeter で HTML から読み込まれるリソースも含めて負荷をかける

そんなこんなで、何とか大晦日までに秒間 1 万ユーザ捌けるシステムを構築することができました。

次回は負荷テストのプロにお願いしてみたい

今回は JMeter を使いましたが、テストプランに穴があったとも限りませんし、ロングランテストや 3G 回線のスマホ、タブレット等のスロークライアントを想定したテストも十分にできませんでした。

なので、つぎに高負荷に耐えられるようなシステムの負荷テストをする際には、負荷テストのプロにお願いしてみるというのも視野に入れてみたいと思います。

自分たちで作ったものは、どうしても壊れないようにやさしく扱っちゃいがちです。 そんななかで、自分たちで作ったシステムを無慈悲にいじめ抜いてくれる第三者いたら心強いですしね。

ちなみに、大晦日前に発売された『過負荷に耐えるWebの作り方』という本には、NRIセキュアという会社が紹介されていました。

Web サイトに対して負荷テストを実施する際は、複数の HTML やその HTML から読み込まれる CSS や JS、画像などのリソースへの負荷もかけられると、実際にユーザがブラウザからアクセスしたときにかかる負荷に近い負荷テストができます。

ab や httperf などでも複数リソースに対してのリクエストができないわけではありませんが、JMeter には HTML から読み込まれるリソース群へのリクエストも含めたテストプランが簡単に作成できる仕組みが標準でついています。

ブラウザから JMeter のローカルのプロキシサーバ越しにリクエストを送ることで、HTTP リクエストのサンプラーを自動でリストアップしてくれるので、自作のプログラムや手作業でリストを作成する必要がありません。

JMeter プロキシサーバの設定

JMeter を起動すると、WorkBench という項目がすでにあるので、右クリックでメニューを表示して Add > Non-Test Elements > HTTP(S) Test Script Recorder を選択します。

そうすると WorkBench の下層に HTTP(S) Test Script Recorder という項目ができます。

Start ボタンを押すとプロキシサーバが立ち上がり、以降 Stop ボタンでサーバを停止するまでの間に、プロキシサーバ越しに送られるリクエストが、HTTP リクエストサンプラーとしてリストアップされることになります。

今回は設定はデフォルトのままにしておきました。

あと、サンプラーのリストアップ先の Thread Group も作成しておきます。

これで、JMeter 側の設定は完了です。

ブラウザの設定

次は、ブラウザのリクエストを JMeter のプロキシサーバに向ける設定をします。 今回使用するブラウザは Chrome で、Proxy SwitchySharp というエクステンションを使用します。

インストールが終わったら、設定ページを表示して、Proxy Profile タブから以下のような設定で新規プロファイルを作成します。

Proxy SwitchySharp のメニューから先ほど作成した「JMeter Proxy」というプロファイルを選択することで、Chrome からのリクエストがローカルホストの 8080 番ポートに向くようになります。

最後に、JMeter のプロキシサーバを起動して、負荷テスト対象のページにブラウザからアクセスすると、先ほど作成した Thread Group 以下にサンプラーがリストアップされます。

あとは Listener を追加して、煮るなり焼くなり好きにしましょう。 ちなみに、今回の設定方法は以下のサイトを参考にさせていただきました。