プログラマでありたい

おっさんになっても、プログラマでありつづけたい

AWSのアカウント管理の話

  AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。

 運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。

AWSのアカウントの種類



 AWSで利用するアカウントは2種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで1つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。

AWSアカウントの取扱について



 AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが基本となります。また、デフォルトではメールアドレスとパスワードのみで認証となります。アカウント作成した段階で、二要素認証の導入を強く推奨します。
 AWSでの二要素認証には、ハードウェアまたは仮想MFAデバイスを利用できます。ハードウェアについては、AWSのページから購入可能です。現在は、キータイプのものとカードタイプのものの2種類が購入可能です。仮想MFAデバイスについては、スマホやPCにインストールして利用します。iOSであれば、GoogleのAuthenticatorなどがあります。PCの場合は、Chromeの拡張などを利用すると便利です。
 AWSアカウントのMFAの選定については、どのような利用をするかがポイントになります。何故ならAWSアカウントには、接続元のIPアドレス制限が出来ません。その為、特定の場所からのみしか接続できないという運用を確実に行うには、物理MFAを設定して持ち運べないようにする必要があります。具体的なアドバイスとしては、金庫を買って放り込んでおくのが確実です。

IAMアカウントの取扱について



 IAMについては、IAMユーザとIAMグループ、IAMロールがあります。IAMユーザは個々のユーザに配布するもので、上の方でIAMアカウントと呼んでいたものです。IAMグループは、IAMユーザに所属させることにより一括で権限管理が出来るようになります。IAMロールはインスタンスに紐付けるものです。
 AWSを運用する上では、IAMの利用が基本となります。まずIAMユーザとグループの使い分けですが、組織で利用する上ではIAMユーザには基本的には認証の情報のみ設定し、権限に関する情報を付与しない方が良いと思います。理由としては、ユーザごとの設定で漏れなどを発生する確率を少しでも下げるためです。またそれ以前のAWSの仕様として、IAMユーザに付与できるポリシーのバイト数がIAMグループより小さいということがあります。その為、IAMユーザには複雑なポリシーを付与しにくいです。図でまとめると次のような形になります。

f:id:dkfj:20141207014716p:plain

IAMのポリシー設計について



 IAMで利用できるリソース等をIAMポリシーと呼びます。ポリシーについては、許可(Allow)/禁止(Deny)を組み合わせて記述します。記述の際には、3つの原則を理解しておく必要があります。

  1. 初期状態では、どの機能も利用することが出来ない(デフォルト拒否)
  2. 許可を付与することで、指定されたリソースが利用できる
  3. 同一の条件で、許可と禁止の両方を指定された場合は禁止になる(明示的拒否の優先)

 マトリックスにすると、次のようになります。

f:id:dkfj:20141207020558p:plain

 じゃぁ必要なものだけ単純に許可していけば良いかというと、そうでもなかったりします。例えば、EC2やS3といったサービスレベルであれば、それでも問題はないです。しかし、EC2のネットワーク機能を除いてといったことをすると、途端にややこしくなります。方法としては、EC2の機能を全部許可した上でネットワークに関するアクションを明示的に拒否していく(Allow-Deny)か、ネットワーク以外のアクションを許可していくということで実現できます。許可制の場合であれば、アクションが増える度に追加していく必要があり面倒くさいです。かつ、アクションが増えても明示的にアナウンスされることはないです。それならば、Allow-Denyで行くかというと都合が悪いケースもあります。
 例えば、機能単位でグループを作っていって、複数のグループに所属させることによってユーザの権限の強弱をつける場合があります。この場合のメリットとしては、個々のグループのポリシーをシンプルに保てるという点にあります。しかし、この方法だと拒否優先の原則が有るために、グループ重ねの効力が発揮されないケースが出てきます。

 そんな時に重宝するのが、NotActionです。NotActionは、指定されたものを反転して許可します。Allow-Actionでec2を指定した場合は、ec2が許可されます。Allow-NotActionでec2を指定した場合は、ec2以外の全てのリソースが許可されます。ややこしいので図にすると次のような形になります。
f:id:dkfj:20141207022153p:plain

 それぞれのポリシーは、次のような形です。

{
  "Statement":[
    {
      "Effect":"Allow",
      "Action":"ec2:*",
      "Resource":"*"
    }
  ]
}
{
  "Statement":[
    {
      "Effect":"Allow",
      "NotAction":"ec2:*",
      "Resource":"*"
    }
  ]
}

IAMのポリシーの管理について



 ストレートにCloudFormationで記述して、Gitなどのバージョン管理システムで管理しておきましょう。ポリシー自体をExcel等で管理しようとすると大変です。(ポリシー設計をExcelで管理するのは、別に構わないと思います。)

まとめ



 NotAction便利だよと書きたかっただけです。あまり日本語の情報はありません。ちょっとでも知られるキッカケになればと思います。後は、セキュリティを高める為には、やはりアカウントの適切な運用が第一歩だと思います。その辺りについての知見が共有されるようになればと思います。

See Also:
クローラーとAWSが出会ったら?第3回Webスクレイピング勉強会@東京
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き
アプリケーション・サーバのセッションの保存先の話

参照:
AWS Advent Calendar 2014
IAM Policy Statementにおける NotAction / NotResource とは? : Developers.IO
Permissions and Policies - AWS

S3のイベント通知機能(S3 Event Notifications)に対するユースケースを考える

 日本のAWS関係者がre:Inventの発表で盛り上がっているなか、風邪ひいて寝込んでました。季節の変わり目には、気をつけましょう。
 さて、そんな感じで全然追いつけていませんが、特に面白いなぁと思ったのが、S3 Event NotificationsとAWS Lambdaです。Lambdaについてはまだ触っていないので何ともいえない部分がありますが、発表内容を見る限りインフラの在り方を変えるような存在かもしれません。そして、S3のEvent Notifications。これ、めちゃくちゃ便利です。S3のイベント(現在は、putとpushとcopy)が発生したら、SNSやSQSに通知を送れるという機能です。何が便利かというと、ファイルのアップロードをトリガーに処理を書けるということです。頭に浮かんだユースケースを1つ書いてみます。

S3 Event Notificationsを使ったクローラーのユースケース



 最近、クローラー開発のステマばかりしているので、今回もそのケースで説明してみます。処理の流れとしては、下記のようなものを想定します。

  1. データをダウンロードする
  2. ダウンロードしたデータを生データとしてS3に保存する
  3. S3の未処理の生データを取得して、加工処理をおこなう

 この処理の中で、3の部分が少し曲者になります。未処理のデータが何かというのを特定する方法が必要になるからです。今までの対処方法としては、次のような方法が考えられます。

  • 処理前/済みのデータを管理するデータベース等を用意する
  • 処理前と処理済みでディレクトリをわけて、処理が終わったら移動させる
  • 2の保存と同時に、SQSに登録する

 一手間があって面倒くさいというのが実情でした。また、処理サーバを複数にすると排他制御の仕組みが必要になり、複雑になります。3の処理が一番楽なのですが、S3に直接データだけアップしたいというようなケースには対応できません。

 S3 Event Notificationsを使えばどうなるのでしょうか?
下に簡単な図を載せていますが、クローラーはただデータを集めて保存するだけに徹すればよいことになります。その後のS3⇒SQS⇒(EC2上での)処理は、良きに計らえという状態になります。疎結合なアーキテクチャになりますよね。また処理サーバをキューの数に応じたAutoScaleにしておいたら、処理が溜まったら自動的に増強してくれます。

f:id:dkfj:20141115131937p:plain

S3 Event Notificationsをユースケースの妄想



 この他にも、いろいろな使い道が考えられます。みなさん、いろいろ妄想してみてください。

  • ElasticTranscodeと連携して、アップロードしたら動画変換
  • サーバーレスで、SNSを発行するトリガー
  • (Getイベントに対応したら)メッセージを読んだら自動的に削除
  • (Getイベントに対応したら)メッセージを読んだら自動的に爆発

S3 Event Notificationsの使い方



 未来有望なS3 Event Notificationsです。妄想するだけでなく、実際に使ってみましょう。通知を送るだけであればAWSマネージメントコンソールだけで簡潔できます。

手順としては、次の通りです。

  1. SQS(SNS)を作成し、パーミッションの設定をする
  2. 新規もしくは既存のS3バケットに、Event設定をする
  3. ファイルをアップロードする
  4. SQS(SNS)を確認する

 まず1つ目ですが、今回はSQSの例を紹介します。ポイントは、パーミッション設定です。
対象のバケットからの通知を許可します。具体的には、SourceARNでStringLikeの条件をつけます。

f:id:dkfj:20141115133107p:plain

 2つ目のS3バケットへの設定は、簡単です。
バケットのPropertyの、Eventの項目を設定します。

f:id:dkfj:20141115133258p:plain

 先ほどの権限設定がうまくいっていないと、下記のようなエラーがでます。

Unable to validate the following destination configurations :Permissions on the destination queue to not allow S3 to push notifications from this bucket

 ファイルをアップロードすると、設定が上手くいっていればSQSの画面からキューが登録されているのを確認できます。
f:id:dkfj:20141115133536p:plain
f:id:dkfj:20141115133604p:plain

感想



 とっても便利です。システムの肝は、疎結合&シンプルだと思います。それを実現するために、さらに便利な機能が追加されたと言えるでしょう。更にAWS Lambdaと組み合わせれば、いろいろな事が出来そうです。楽しみ!!

今どきのサーバ/インフラの構築の仕方。"サーバ/インフラ徹底攻略 (WEB+DB PRESS plus) "

f:id:dkfj:20141028062740j:plain

 10/30発売の「サーバ/インフラ徹底攻略 (WEB+DB PRESS plus) 」を、@imai_factoryさんに献本頂きました。ありがとうございます。まだパラパラめくっている状態ですが、最近のサーバ/インフラの構築・運用方法の潮流について、これ1冊で解る内容になっていて面白いです。

サーバ/インフラ徹底攻略とは?



 WEB+DB PRESSに掲載されたサーバ/インフラ関連記事を再編集したものです。2013年後半から2014年の記事が中心となっているので、取り扱うトピックスとしてもホットなものが多いです。かつ、ある程度時間が経っていることもあり、数ある類似の技術の中で定着しつつあるものが選ばれている印象です。

章ごとの感想


[入門]コードによるインフラ構築

 入門Chef SoloによってInfrastructure as Codeの概念を一気に普及させた@naoya_itoさんによるコードによるインフラ管理の話です。ChefとVagrant、Serverspecを利用して、実践例を解説しています。適度な難度のものを丁寧に説明されてるので、初めての人にちょうど良いと思います。私も、入門Chef Solo片手に動かしながら覚えました。
 ちなみに、この本は章ごとに技評の本の宣伝がされています。この章の末の紹介書籍は、この2冊です。納得です。

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

Amazon Web Services最新活用

 この章は、Amazonが誇るソリューションエンジニア(SA)陣による、AWSの紹介です。25ページ程の枠の中で、AWSのサービスの概要と概念、主要なサービスの紹介をポイント抑えて説明しているところは流石です。あらには、構築自動化という本書のテーマに沿って、CloudFormationとChefの組み合わせなど実践的な内容まで載っています。これからAWSをやってみようという人には、30分くらいでだいたい解るという内容になっています。流石です。
 章末の紹介書籍は、下記の2冊です。クラウドを支える技術は、Googleのクラウドの話なので苦渋の選択だったのではと思います。意外なことに、技術評論社さんからAWS関係の書籍でてないっぽいですね。

クラウドを支える技術 ―データセンターサイズのマシン設計法入門 (WEB+DB PRESS plus)

クラウドを支える技術 ―データセンターサイズのマシン設計法入門 (WEB+DB PRESS plus)

  • 作者: ルイス・アンドレ・バロッソ(Luiz André Barroso),ジミー・クライダラス(Jimmy Clidaras),ウルス・ヘルツル(Urs Holzle),Hisa Ando
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/09/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る
コンピュータアーキテクチャ技術入門 ~高速化の追求×消費電力の壁 (WEB+DB PRESS plus)

コンピュータアーキテクチャ技術入門 ~高速化の追求×消費電力の壁 (WEB+DB PRESS plus)

 ちなみに最近のAWSのお勧め本は、「Amazon Web Services 基礎からのネットワーク&サーバー構築」です。同じくAmazonのSA陣による執筆で、AWSのみならずネットワークやサーバ構築の考え方が解る1冊になっています。

Amazon Web Services 基礎からのネットワーク&サーバー構築

Amazon Web Services 基礎からのネットワーク&サーバー構築


テスト駆動インフラ&CI最前線

 この章は、ServerSpecの宮下さんによるテスト駆動開発とCIの話です。インフラのテスト自動化は構築の自動化とセットで、もしくはテスト自動化の方こそ先に導入すべきと考えています。その中で、ServerSpecは一番よい感じのテスト自動化ツールです。振る舞いをチェックするだけなので、ChefやPuppetまたは手作業で作ったサーバにも中立的にテストできます。
 あとGitHub Flowをベースとしたワークフロー変革の話もよいです。「バージョン管理は開発者のしつけ」から「バージョン管理ツールは開発者のコミュニケーションの中心」に変わりつつあるように思えます。その流れの中で、ワークフローどうするのというのが色々なところで議論されています。その中でGitHub Flowは、GitHubを中心としたワークフローのベストプラクティスの一つです。いちど読んでおいたほうがよいですよ。
 
 章末の紹介書籍は、下記の2冊です。GitHub実践入門をこちらにもってきた方が良かったのでは?

フロントエンド開発徹底攻略 (WEB+DB PRESS plus)

フロントエンド開発徹底攻略 (WEB+DB PRESS plus)

  • 作者: cho45(さとう),五十嵐啓人,伊野亘輝,須藤耕平,片山育美,池田拓司,高津戸壮,石本光司,竹迫良範,伊藤直也,若原祥正,沢渡真雪
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/07/16
  • メディア: 大型本
  • この商品を含むブログを見る
Ruby徹底攻略 (WEB+DB PRESS plus)

Ruby徹底攻略 (WEB+DB PRESS plus)

  • 作者: 角征典,成瀬ゆい,そらは(福森匠大),田中哲,笹田耕一,村田賢太,まつもとゆきひろ,松田明,後藤大輔,浦嶌啓太,高橋健一,柴田博志,近藤宇智朗,大和田純,白土慧,原悠(yhara),伊藤直也,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/06/12
  • メディア: 大型本
  • この商品を含むブログ (1件) を見る

実践Immutable Infrastructure

 はてなのCTOの田中さんによるImmutable Infrastructureの話です。2013年くらいから話題になってきたImmutable Infrastructureですが、クラウドの台頭で大量のサーバを増減させながら運用するようになって、サーバがどうあるべきかという姿の話だと思います。サーバを上げたり下げたりしていると、ステートレスにしておかないと面倒くさいことこの上ないんですね。10台規模くらいだったら手動でも何とかなるけど、数百台規模になると仕組みから考えないといけないという世界なのだと思います。Blue-green Deploymentなど、最近のデプロイ方法の実例など面白いです。

データベース徹底攻略 (WEB+DB PRESS plus)

データベース徹底攻略 (WEB+DB PRESS plus)

  • 作者: 松信嘉範,羽生章洋,ミック,奥野幹也,松下雅和,桑野章弘,青木峰郎,ひろせまさあき,小林篤,島田慶樹,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/03/15
  • メディア: 大型本
  • この商品を含むブログ (2件) を見る
Webサービス開発徹底攻略 (WEB+DB PRESS plus)

Webサービス開発徹底攻略 (WEB+DB PRESS plus)

  • 作者: 勝間亮,石田忠司,杉谷保幸,江口滋,上谷隆宏,青木俊介,久保達彦,池邉智洋,谷口公一,田淵純一,伊野友紀,西岡拓人,吉田俊明,古旗雅史,木野瀬友人,かなだまさかつ,牧本慎平,成田一生,舘野祐一,濱崎健吾,鈴木慎之介,齊藤宏多,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/01/26
  • メディア: 大型本
  • 購入: 6人 クリック: 65回
  • この商品を含むブログ (3件) を見る

[詳解]nginx

 本全体の流れの中で、少し唐突感があるのがnginxの特集です。ただ、最近Apacheとnginxの使い分けが増えてきたので、さらっと抑えておくには良い特集です。未だに字面をみてnginx(エンジンエックス)の読み方が解らなくなります。どこをどうやったら、この読み方になるのでしょうか?

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

  • 作者: 小飼弾,田籠聡,近藤宇智朗,並河祐貴,赤松祐希,井上誠一郎,ミック,天尋左石,和田裕介,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/07/23
  • メディア: 大型本
  • この商品を含むブログ (6件) を見る
JavaScript徹底攻略 (WEB+DB PRESS plus)

JavaScript徹底攻略 (WEB+DB PRESS plus)

  • 作者: 沖林正紀,吾郷協,高橋征義,名村卓,桜井雅史,縣俊貴,太田昌吾,天野祐介,飯塚直,佐藤鉄平,冨田慎一,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/01/26
  • メディア: 大型本
  • 購入: 7人 クリック: 69回
  • この商品を含むブログ (6件) を見る

メンテナンス本格入門

 いちばん面白いなぁと思ったのが、この章です。サーバーエージェントの技術者陣によって、運用や障害対応など実際の現場での対応方法が紹介されています。こういった情報は勉強会でたまに聞くことが出来ますが、本で読める機会というのは中々ないです。そういった意味で、かなり貴重な資料でしょう。読んでいるとあるあるが多すぎて、いろいろ苦労してきてインフラを支えているのだなと想像でき、胃が痛くなってきます。運用を踏まえての設計は、先人の知恵の結晶です。是非、先人の屍を乗り越えていきましょう。

全体の感想



 この本読んで、WEB+DBの連載陣のレベルの高さは凄いなと思います。毎月読んでたら、だいたいのトレンドは抑えられます。といっても、雑誌なのでテーマカットで掲載するのは難しいので、こういった総集編は良い切り口だなと思います。個々の内容については入り口のところまでの紹介なので、そんなに時間が掛けずに目が通せるので一度読んでおくと良いのではないでしょうか。

サーバ/インフラ徹底攻略 (WEB+DB PRESS plus)

サーバ/インフラ徹底攻略 (WEB+DB PRESS plus)

  • 作者: 伊藤直也,片山暁雄,平山毅,舟崎健治,吉荒祐一,今井雄太,八木橋徹平,安川健太,宮下剛輔,田中慎司,久保達彦,道井俊介,飯田祐基,桑野章弘,松浦隼人,中村俊之,福永亘,杉山仁則,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/10/30
  • メディア: 大型本
  • この商品を含むブログ (2件) を見る

サーバ/インフラ徹底攻略の目次



 念のため、目次つけておきます。

巻頭企画
[入門]コードによるインフラ構築
サーバ構成管理の自動化を実現するる……伊藤 直也
第1章 ChefとVagrantによるインフラのコード化
設定の一元管理で作業を省力化する
第2章 Serverspecによるテスト駆動インフラ構築
設定変更の反映を確実なものにする
特集1
Amazon Web Services最新活用
レイヤ別比較,構築の定石,構成管理の自動化る
第1章 Amazon Web Servicesレイヤ別比較
各サービスの特徴を理解し,うまく使い分ける……片山 暁雄,平山 毅
第2章 EC2とVPCによるシステム構築
セキュアで可用性を高めたインフラの作り方……舟崎 健治,吉荒 祐一
第3章 RDSによるデータベースの活用
作成,デプロイ,バックアップ……今井 雄太,八木橋 徹平
第4章 CloudFormationによる構築の自動化
テンプレートの作成からミドルウェア構築設定まで……安川 健太
特集2
テスト駆動インフラ&CI最前線
Infrastructure as Codeがもたらすワークフローの刷新る……宮下 剛輔
第1章 インフラのテストとその重要性
「インフラのコード化」による開発手法の応用
第2章 テスト駆動インフラの実践
VirtualBox,Vagrant,Puppet,Serverspecによるテスト自動化
第3章 インフラCIの実践
GitHub,Wercker,DigitalOceanによる継続的テスト
第4章 インフラの継続的改善の実践
GitHub Flowをベースとしたワークフロー変革
特集3
実践Immutable Infrastructure
使い捨てサーバによる運用の変革る……田中 慎司
第1章 Immutable Infrastructureとは何か
不変なサーバ,Blue-green Deploymentとそれらの利点
第2章 Immutable Infrastructureで利用するツール/サービス
比較・整理と,システム全体での組み合わせ
第3章 コンテナ型仮想化とクラウドによる実践
Docker+HAProxy,Amazon EC2+ELB
第4章 クラスタ管理ツールによる実践
Apache Mesosでリソース管理の自動化
特集4
[詳解]nginx
設定の柔軟性と優れたスケーラビリティ
第1章 nginxの世界へようこそ
アーキテクチャ,用途,メリット,デメリット……久保 達彦
第2章 はじめてのnginx
インストール,起動と終了,基本設定……道井 俊介
第3章 一般的なWebサーバの構築
バーチャルホスト,アクセス制御,SSL通信,基本認証……飯田 祐基
第4章 実践的なWebアプリケーションサーバの構築
Unicorn/RailsやPHP-FPMと連携させる……道井 俊介
第5章 大規模コンテンツ配信システムの構築
キャッシュ,ロードバランシングを活用する……飯田 祐基
第6章 拡張モジュールのしくみと作り方
nginxを自由にカスタマイズするための基礎知識……久保 達彦
特集5
メンテナンス本格入門
緊急対応,計画停止,メンテフリー化
第1章 メンテナンスとは
種類と手法を整理する……桑野 章弘
第2章 計画メンテナンスの流れ
事前準備,作業のチェック,振り返り……松浦 隼人
第3章 緊急メンテナンスの流れ
普段から備えるべきこと,障害時の対応……松浦 隼人
第4章 メンテフリーへのアプローチ【インフラ編】
省力運用を実現するインフラ,データベース設計と障害検知……松浦 隼人,中村 俊之
第5章 メンテフリーへのアプローチ【アプリケーション編】
ダウンタイムを減らすリリース手法とアプリケーション設計……福永 亘,中村 俊之,松浦 隼人
第6章 ガールフレンド(仮)とアメーバピグの事例
現場でどう実践し,どう障害を切り抜けたか……福永 亘,杉山 仁則
一般記事
Dockerで軽量な仮想環境
Linuxコンテナでインフラを瞬時に構築する……伊藤 直也

See Also:
Statelessなサーバについて 〜クラウド時代のサーバの在り方
何故、fluentdなのか?
Immutable InfrastructureとChefと冪等性の話
手動でサーバの設定をすることを禁ずる。入門Chef Solo

クローラーとAWSが出会ったら?第3回Webスクレイピング勉強会@東京

 2014/10/26に開催された第3回Webスクレイピング勉強会@東京に参加して、発表してきました。今回は、スクレイピングと少し離れてAWSを使ってクローリングするという話です。クローラー/スクレイピングとAWSは相性が良いというのは、昔から思っていたのでテーマとして扱うことは早めに決めていました。しかし、話の構成を、具体的なテクニックの話にするか、概念的な話にするか、少し悩みました。なるべき多くの人に伝わるように、概念的な話をしたつもりです。具体的な部分についてはRubyによるクローラー開発技法を読んで頂ければと思いますw

発表資料



Scraping withawsAWSを利用してスクレイピングの悩みを解決するチップス

 資料の構成としては、クローリングする際の悩みをあげた上で、AWSを使えばどう解決できるのかという構成にしています。AWSのサービスの簡単な紹介と、クローラーを作成する上で便利なサービスを3つ挙げています。EC2とS3,SQSです。前の2つのサービスについては納得すると思いますが、SQSについては何故と思う方もいるかもしれません。その辺りを構成含めて、簡単に紹介しています。
 

他の方の発表資料



 今回は、オープニングを含めて7人の発表がありました。どれも面白く、参考になりました。

Webスクレイピング勉強会@東京 オープニングトーク (第3版) #東京スクラッパー


クローリングしにくいものに挑戦 公開用
 @luminさんは、本職でスクレイピングしているプロとあって非常に濃い内容でした。スクレイピングの上級編は、プロトコル解析から始まるとのことです。なかなか到達できない世界ですね。


ソーシャル・スクレイピング(2014年10月Webスクレイピング勉強会資料)
 @YuzoAkakuraさんは、マスコミで働いているシステムエンジニアとのことです。データジャーナリズムという未知の分野を垣間見せて頂けました。データジャーナリズムとは、「データからニュースを発見し、わかりやすく伝える手段」とのことです。凄く合点がいきました。


第3回Webスクレイピング勉強会@東京 happyou.info

 @shogookamotoさんは、自作のスクレイピングサービスの紹介でした。上場企業や政府機関をスクレイピングしてRSSで配信するという素敵なサービスです。紹介としては1行でさらっと言えるないようですが、取得対象を解析して、それぞれに対応するというのは並大抵の労力ではなかったと思います。凄いサービスです。

20141022 リサーチ向け・ブラウザだけでスクレイピング(浅野)
 @hirosuke_asanoさんは、コピペで出来るスクレイピングを紹介しています。これも規模によっては、よくやります。スクレイピングは手段にすぎないので、用途や個人のスキルに応じて、適切なものを選べばよいのですよね。

実践Excelスクレイピング
 @h_sinoharaはネタっぽく語られていましたが、非常に共感がいく内容でした。Perlで苦労した話とか、Excelでスクレイピングするとか、いろいろ通った道ですね。特にExcelスクレイピングについては、もっと多くの人に知って貰えればと思います。web::queryは必殺技

Togetter



 Togetterのまとめも作っています。ハッシュタグ #東京スクラッパー から抽出しています。

第3回Webスクレイピング勉強会@東京のまとめ - Togetterまとめ


感想



 どれも見応えのある内容で、非常に楽しかったです。私の発表については、AWSの便利さが伝わったようです。ただ、懇親会等で話を聞いていると、まだまだクラウド破産を恐れる人が沢山いるということが解りました。これは、長年使っていると、全く気にならなくなります。ただ、外から見るとそのような恐れがあるというは、改めて認識できるようになりました。同じカテゴリーの人と話していては気がつかないことですね。ありがたいです。
 また、Pythonのクローラー本に対するリクエストが多かったです。しばらく動けそうにないので、誰かやりたい人がいたらご連絡くださいw

PR
anemoneの解説を含めて、Rubyによるクローラー開発の本を書きました。
クローラーの概念から実際の構築・運用手順を網羅しています。


See Also:
RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京
「第2回Webスクレイピング勉強会@東京」に参加&発表してきました
『Rubyによるクローラー開発技法』を書きました
Rubyによるクローラー開発技法の目次
個人ブログの存在感は、自分が思っているより大きいのかもしれない。或いは書籍の流通の話
『Rubyによるクローラー開発技法』の増刷決定しました
本を書く前に準備したこと、執筆中にしていたこと


参照:
第3回Webスクレイピング勉強会@東京(最終回)

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Bees with machine gunsを使って負荷テスト

 静的サイトの運用であれば、現状ではS3 Web Hosting機能が最適と考えています。OSやミドルウェアのアップデートも不要で、かつ仮想サーバを起動するより圧倒的に安価です。一方で、ほぼ無敵のS3といえども、一定時間で過剰なアクセスがあった場合はスロットリング(throttling)といって、規制されてアクセス制限が掛かる可能性があります。しかし、その閾値がどれくらいなのか、謎です。(全体のリソース状況によるので、一定ではないとのこと)
 ちょっと試してみたかったので、負荷テストをおこなってみました。S3に対する負荷テストの場合、そんじょそこらの負荷では太刀打ち出来ません。そこで、複数のサーバから負荷を掛けてみることにしてみました。と言っても、複数のサーバをコントロールするのは面倒臭いので、Bees with machine gunsを使ってみました。

Bees with machine gunsとは?



 Python製の負荷テストツールです。Bees with machine gunsをインストールしたマシン(親機)から、Beeとよばれる子機(EC2 micro instance)を操作します。子機は、任意の数を起動可能です。複数のBeeから一斉に負荷を掛けて、最後に親機で集計します。負荷テスト自体は、Apache Benchを利用しているようです。
f:id:dkfj:20140728051149p:plain

Bees with machine gunsのインストール



Bees with machine gunsは、以下のモジュールに依存しています。

  • Python 2.6
  • boto
  • paramiko

 特別なものが無いので、楽勝と思いきやハマりました。Amazon Linuxを利用してたのですが、手順通り進めていくと、下記のようなエラーにぶち当たります。

/usr/lib64/python2.6/site-packages/Crypto/Util/number.py:57: PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.
_warn("Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.", PowmInsecureWarning)

Traceback (most recent call last):
File "/usr/bin/bees", line 3, in
from beeswithmachineguns import main
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 27, in
import bees
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 36, in
import paramiko
File "/usr/lib/python2.6/site-packages/paramiko/__init__.py", line 69, in
from transport import SecurityOptions, Transport
File "/usr/lib/python2.6/site-packages/paramiko/transport.py", line 32, in
from paramiko import util
File "/usr/lib/python2.6/site-packages/paramiko/util.py", line 32, in
from paramiko.common import *
File "/usr/lib/python2.6/site-packages/paramiko/common.py", line 98, in
from Crypto import Random
File "/usr/lib64/python2.6/site-packages/Crypto/Random/__init__.py", line 29, in
from Crypto.Random import _UserFriendlyRNG
File "/usr/lib64/python2.6/site-packages/Crypto/Random/_UserFriendlyRNG.py", line 38, in
from Crypto.Random.Fortuna import FortunaAccumulator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaAccumulator.py", line 39, in
import FortunaGenerator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaGenerator.py", line 36, in
from Crypto.Cipher import AES
File "/usr/lib64/python2.6/site-packages/Crypto/Cipher/AES.py", line 50, in
from Crypto.Cipher import _AES
ImportError: /usr/lib64/python2.6/site-packages/Crypto/Cipher/_AES.so: undefined symbol: rpl_malloc

 暗号化あたりのモジュールの問題のようで、GNU MPとMPIRを入れ替えた上で、再ビルドが必要のようです。この辺りを参考に、設定します。
The Bug Charmer: Building PyCrypto on Amazon EC2

# yum groupinstall "Development Tools"
# yum install python-devel
# 
# ./configure
# make
# make check
# make install
# wget https://ftp.gnu.org/gnu/gmp/gmp-6.0.0a.tar.bz2
# bzip2 -dc gmp-6.0.0a.tar.bz2 | tar xvf -
# cd gmp-6.0.0
# ./configure
# make
# make check
# make install
# wget http://www.mpir.org/mpir-2.6.0.tar.bz2
# bzip2 -dc mpir-2.6.0.tar.bz2 | tar xvf -
# cd mpir-2.6.0
# ./configure
# make
# make check
# make install
# yum reinstall python
# wget http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.tar.gz 
# tar xzvf pycrypto-2.6.tar.gz 
# cd pycrypto-2.6
# vi configure
if test $ac_cv_func_malloc_0_nonnull = yes; then :

$as_echo "#define HAVE_MALLOC 1" >>confdefs.h

#else
#  $as_echo "#define HAVE_MALLOC 0" >>confdefs.h

#   case " $LIBOBJS " in
#  *" malloc.$ac_objext "* ) ;;
#  *) LIBOBJS="$LIBOBJS malloc.$ac_objext"
# ;;
#esac


$as_echo "#define malloc rpl_malloc" >>confdefs.h

# pip uninstall PyCrypto
# python setup.py build
# pyton setup install
# pip install beeswithmachineguns

インストール後に、botoの設定を行ないます。.botoファイルとpemの用意をします。

vi ~/.boto
[Credentials]
aws_access_key_id = 'your access key'
aws_secret_access_key = 'your secret access key'

Bees with machine gunsの利用



 設定が全て終わっていれば、次のようなコマンドでBee(子機)の起動できます。

bees up -s 4 -g セキュリティグループ名 -k pemファイル名

 -sが起動するサーバ数、-gがセキュリティグループ名です。注意点としてはNon-VPCのネットワークで起動するので、Non-VPCのセキュリティグループを作成しておく必要があります。そして、親機からsshでアクセス出来るようにしておく必要があります。

 負荷テストは、次のような形です。
nが負荷リクエストの総数。cが同時接続数です。少ない台数で同時接続数を上げ過ぎると、処理しきれずにエラーがでます。注意点としては、/で終わるURLでないとテストできません。

# bees attack -n 10000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 4 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 4 bees will fire 2500 rounds, 62 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 3 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 1 is firing his machine gun. Bang bang!
Bee 1 is out of ammo.
Bee 0 is out of ammo.
Bee 2 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     Complete requests:		10000
     Requests per second:	406.720000 [#/sec] (mean)
     Time per request:		621.828500 [ms] (mean)
     50% response time:		544.250000 [ms] (mean)
     90% response time:		804.250000 [ms] (mean)
Mission Assessment: Target successfully fended off the swarm.
The swarm is awaiting new orders.

 上記の結果をみると、毎秒406リクエストをこなしていたのが解ります。念の為、アクセスログを見てみると、全て200 O.K.でした。

 では、S3の限界に挑戦する為に、台数を増やしてみます。追加でBeeを増やせないようなので、一度落とします。

# bees down

 10台立ててみました。Beeが一杯です。
f:id:dkfj:20140728051259p:plain

# bees attack -n 100000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 10000 rounds, 25 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
Bee 5 is firing his machine gun. Bang bang!
Bee 6 is firing his machine gun. Bang bang!
Bee 3 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 8 is firing his machine gun. Bang bang!
Bee 4 is firing his machine gun. Bang bang!
Bee 4 is out of ammo.
Bee 6 is out of ammo.
Bee 0 is out of ammo.
Bee 5 is out of ammo.
Bee 2 is out of ammo.
Bee 8 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     3 of your bees didn't make it to the action. They might be taking a little longer than normal to find their machine guns, or may have been terminated without using "bees down".
     Complete requests:		70000
     Requests per second:	330.450000 [#/sec] (mean)
     Time per request:		529.952571 [ms] (mean)
     50% response time:		523.142857 [ms] (mean)
     90% response time:		548.285714 [ms] (mean)

 3台のBeeが行方不明になってしましました。親機の性能不足でしょうか?それとも、子機の性能不足でしょうか?念の為、親機をc3.largeに変更しておきます。

 同時接続数を減らして、再度実行します。

# bees attack -n 10000 -c 200 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 1000 rounds, 20 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
No handlers could be found for logger "paramiko.transport"
Traceback (most recent call last):
  File "/usr/bin/bees", line 5, in <module>
    main.main()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 127, in main
    parse_options()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 119, in parse_options
    bees.attack(options.url, options.number, options.concurrent)
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 325, in attack
    results = pool.map(_attack, params)
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 148, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 422, in get
    raise self._value
AssertionError: PID check failed. RNG must be re-initialized after fork(). Hint: Try Random.atfork()

 paramiko.transportのエラーがでました。

感想



 この後も、何度もパラメータや起動台数を変更しながら試してみました。どうも台数や接続数が多いと安定しない模様です。もう少し、調べてみる必要があります。S3 WebHositingに関して言えば、秒間400接続くらいであれば、余裕でこなせる模様です。流石!!


参照:
newsapps/beeswithmachineguns · GitHub
The Bug Charmer: Building PyCrypto on Amazon EC2

夏のJAWS-UG 三都物語 2014でCDP道場に入門してきました

f:id:dkfj:20140708075033j:plain
(西島さん、撮影の写真)


 7/5に開催された夏のJAWS-UG 三都物語 2014で、もう1つのネタです。一度はやってみたいと思っていた、CDP道場に初めて参加してきました。もともとスタッフとしての参加でしたが、JAWS−UG沖縄の西島さんの尽力のお陰で、当日まで何もせず手ぶらで参加してチームリーダするだけで済みました。ありがとうございます&役に立たずにすいません。

CDP道場について



 お題とチームの回答については、今後も使い回しをする可能性があるので省略します。(正直言うと、お題のURLも結果のアーキテクチャの写真も残しておくのを忘れてました。)私のチームには、AWSを普段使いしている人はいなかったものの、オンプレミスでのアーキテクチャ設計が豊富な人がいたので、やりたいことをAWSでどう実現するかを翻訳するだけで、ほぼアーキテクチャが完成しました。その点、非常にチームに恵まれていました。チームメンバーの皆さん、ありがとうございました。
 ちなみに初めて参加だったのですが、経験者としてCDP道場に参加するのは、どこまで引っ張って良いか非常に悩ましいです。今回の場合は、アーキテクティングの時間が、1時間と非常に短かかったです。AWSに関しては初心者の方が殆どなので、調べながらではタイムアウトになることは目に見えていました。となると、AWS難しいという印象だけ残して帰っていくことになるかもしれません。一方で、私が主体となってやると、恐らく置いてけぼり感が満載で、面白くないでしょう。そう言った点で、非常にさじ加減が難しかったです。最後の方は、時間がなくてちょっと答えを出し過ぎてしまいました。
 初心者向きであれば、AWSの各サービスのチートシートを作って、30分で説明して2時間くらいあれやこれやが出来ればなぁと思いますが、全体の尺が非常に長くなるので中々難しいですね。アーキテクチャの選択ごとに、関係するサービスの説明をしていたのですが、短い時間でどこまで伝えられたか自信がないです。

セッションストアと外接について



 最後に、AWSの堀内さんを始めJAWSUGのコアメンバーの猛者に色々とツッコミを頂きました。印象に残ったのが2点。1つ目は、セッションストアにElastiCacheという選択に対して、MultiAZをどう対応させるかという指摘です。これは、ElastiCacheのMemcachedがAZを跨いでCache Clusterを構築できないことに起因します。セッションストアにMemcachedを使うというアイデアに、それならElastiCacheがあるよという脊髄反射をして、その辺りの考慮を完全に失念していました。
 会場でのディスカッションでは、DynamoDBをセッションストアに使ってはというアイデアなどが出てきました。自分ならどうするかなという所を、改めて考えてみました。まず基本方針としては、以下3点です。

  • セッションストアは、必ずアプリケーション・サーバから別だしにする(ローカルのサーバのメモリにセッションを格納しない)
  • レプリケーション機能は、過信しない(セッション用途で使うのであれば、準リアルの同期(≒レプリケーション)では不足)
  • ELBのスティッキー設定は、補助的に使う(例え同じサーバに割り振られなくても、セッションがある状態にする)

 上記考慮の上で、セッションストアに何を使うかの優先順位です。

  1. アプリケーションがAPIの類であれば、ステートレスにしてセッションを使わない
  2. ミドルウェア/フレームワークで、セッションストアとしてDynamoDBを利用できるのであれば、それを利用する
  3. EC2上にKyotoCabinetを構築して、マルチマスタ構成にする。ただし、アプリ側からはマスタスレイブ構成として、どちらかのAZを優先して接続するようにする。(マスタに接続できない場合は、アプリ側でスレイブに倒す)
  4. 選択肢がない場合は、DBをセッションストアとして利用する
  5. ELBの方でスティッキー設定をした上で、ミドルウェアのセッションのレプリケーション機能を使う
  6. セキュリティ上問題にならないのであれば、署名付きでCooki Storeも検討する

 正直、使うミドルウェアやフレームワーク次第なのですが、みんなどうしているのでしょうか?各言語・フレームワークごとのベストプラクティスをまとめてみたいものですね。(1年ほど前に、考えていました。)
アプリケーション・サーバのセッションの保存先の話


 2点目の指摘事項は、外部システムの接続をサーバから直接で良いのかという点です。要は、外部のシステムと密結合にする危険性についてです。この指摘については、100%同意です。基本的にはSQSをかまして、システム間を疎結合にします。場合によっては、SWFが使えないか考えます。この辺りは、密結合の危険性とSQS,SWFが何ぞやという説明が必要なので、時間切れになってしまいました。

感想



 やってみて解ったのですが、CDP道場は上手くやればどんなレベルの人にも勉強になります。初心者の人は、中級者以上の人がどう考えるのか。また中上級者の人は、AWSやJAWSUGのコアメンバの指摘やディスカッションを通して、別の見方に触れられます。中々、効率的な学習の仕方だと思うので、機会があれば臆せずに積極的に参加すると良いですね。
 ちなみに個人的には、悩む機会が多い共有ストレージやコンテンツ同期の方法でCDP道場やって、色々なパターンを見てみたいと思いました。


See Also:
アプリケーション・サーバのセッションの保存先の話
アプリケーション・サーバのセッションの保存先の話


参照:
CDP道場とは?その1 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その2 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その3 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その4 | 夏のJAWS-UG 三都物語 2014


Amazon Web Servicesクラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド

AWSで新タイプのインスタンス発表。バースト可能なマイクロインスタンスの後継機

f:id:dkfj:20140702220713p:plain


 どこぞの公式ブログっぽいタイトルになりましたが、AmazonのクラウドであるAWSの仮想サーバのec2に新タイプのインスタンスが追加されました。T2タイプです。その名の通り、t1.microの後継です。t1.microは、全インスタンスタイプの中で唯一CPUのバースト特性を持ったインスタンスです。バースト特性とは、短期的(十秒程度)に本来のCPU性能以上のリソースを利用できる機能です。サーバの用途として、普段のCPU使用率は10%以下でたまに跳ね上がるというものは割りと多いので、バースト特性は割りと面白いサービスです。しかし、t1.micorは、メモリが0.613GBです。21世紀になって14年という時を考えると、余りにストイック過ぎました。

T2シリーズとは



 そこで登場したのが、今回のT2シリーズです。ラインナップは、microだけでなくsmall,mediumもあります。当然、メモリも増量です。1GB,2GB,4GBと、それなりのミドルウェアをインストールできるレベルです。価格もm1,m3シリーズより安いです。以下、東京リージョンでの参考価格です。

名前 vCPUs ベースライン性能 RAM (GiB) 1時間あたりのCPUクレジット 1時間あたりの料金 Price / Month
t2.micro 1 10% 1.0 6 $$0.020 $14.60
t2.small 1 20% 2.0 12 $0.040 $29.20
t2.medium 2 40% 4.0 24 $0.080 $58.40

 ベースラインやCPUクレジットの考え方は、バースト特性に深く関わります。どれだけバースト期間が続き、性能がどれくらいでるのかということです。私自身も、まだ深く検証していなので、そのうち試してみたいです。

旧シリーズとの性能・コスト比較



 一般的な話をすると常にCPUの利用率が50%以上を上回っているような使い方をしている場合は、かなり効率的に利用できていると思います。Webサーバ用途などであれば、可用性のために冗長構成を基本とすると、割りと低いCPU利用率になることが多いのではないでしょうか。そんな際に、T2シリーズを利用するとコスト削減効果が高いと思います。参考のために、m1.smallとt2.small、m3.mediumとt2.mediumの対比を見てみましょう。

名前 比較対象 m*シリーズとのCPU m*シリーズとのメモリ比 m*シリーズとのコスト比
t2.micro t1.micro - 1.62倍 0.77倍
t2.small m1.small 1vCPU 1.18倍 0.66倍
t2.medium m3.small 1vCPU 1.07倍 0.79倍

 バースト特性をどう評価するか難しいところがありますが、m1.smallに対してt2.smallのコスト効果が高いことが解ります。

注意点



 t2インスタンスは、r3と同様にHVMタイプのAMIのみ利用できます。HVMは、Hardware Virtual Machineの略で日本語訳が完全仮想です。何に対して完全かというと、もうひとつの仮想化方式であるparavirtual(準仮想)です。旧来のAMIはparavirtual方式で作られていて、最近はHVM形式で提供されることが多いです。色々な所で、いつHVMベースに変えるか議論されていますが、そろそろ新規のインスタンスについてはHVMを使い、旧来のAMIも可能であればHVMに変更するという方向に舵を切ったほうがよさそうですね。

まとめ



 可能であれば、m1.smallはt2.smallに乗り換えた方が良いですよという話です。AMIのHVMからparavirtualへの再構築も、Chefのような仕組みを使っていれば簡単にできるんでしょうね。

参照:
Amazon Web Services ブログ: 【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス