【合格しました!】AWS 認定ソリューションアーキテクト アソシエイト 受験記

AWS認定ソリューションアーキテクト アソシエイトを受験しました。
受験に向けてどんな事をしたのか、そんな勉強をしたのかをまとめます。

結果

合格しました!
得点は74%でした。
試験中に手ごたえがあまりなくドキドキでしたが、無事合格できてうれしいです!

所感

今回、認定取得を目指して学習したことで、AWSの知識が相当増えたと感じます。
具体的には

  • AWSのサービスを使用してシステムをどう構成すればよいのか
  • AWSのおのおののサービスの得意なこと不得意なこと
  • AWSにおけるベストプラクティス

というようなことが学べ、業務にいかすことができると感じています。

認定をとりたい、という方はもちろん、業務で使えるAWSの知識をもっと増やしたい、という方にもおすすめの認定です。

受験記です。

受験前のAWS歴

AWSを本格的に使っているのはここ1年ほどです。使用しているサービスは、EC2、RDS、S3などの基本的なサービスです。
構築するときは、調べながら&先輩に聞きながら、というのがほとんどでした。

勉強期間

約1カ月です。

学習前に行ったこと

1.受験要綱の確認
AWS認定ソリューションアーキテクト アソシエイトから「試験ガイドのダウンロード」ができます。ここを読みます。

2.AWS クラウドサービス活用資料集の「AWS認定試験準備に向けて」という部分を読む
AWS認定試験準備に向けて
AWS公式で、受験に向けてどのようなことをすればよいか公開されています。
ここを読んで参考にしました。
ですが、ここに書いてあることすべてを行ったわけではありません。
たとえば、「QwikLABS」は行いませんでした。中身を見たところ、いままでやったことがあるものだったのでやりませんでした。
また、「認定試験準備ワークショップの受講」も行っていません。

3.ほかの方の体験記を読みあさる
他のかたの体験記を読みあさり、何をもとに勉強すればよいかの参考にさせていただきました。

学習(1) ~対策本を読む~

※以下、学習(1)~と数字がついています。一応数字順に私は行っていきましたが、途中で(3)の途中で(1)もう一回やったりみたいなこともしました。

まずは唯一出ている対策本を読みました。

合格対策 AWS認定ソリューションアーキテクト – アソシエイト

こちらがとても勉強になりました。
ポイントがまとまっており、これを読んだだけでAWSの知識がだいぶ増えました。
これのおかげで業務でAWSを扱うときに自信を持てるようになったと思います。
この対策本は結局3回ほど読み直しました。
合わせて以下の本も読みました。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

1冊目は対策本という位置づけなこともあり、各サービスがものすごく詳しく書かれているわけではありません。2冊目の本もあわせて読むことで知識を補っていきました。

学習(2) ~サンプル問題~

AWS認定ソリューションアーキテクト アソシエイトから「サンプル問題のダウンロード」ができます。
対策本を1周した時点で解いてみました。間隔をつかむためにもやっておいたほうがよいと思われます。
(あまりわからず衝撃を受けます。。。)

学習(3) ~クラウドデザインパターンを知る~

クラウドデザインパターンについて学びました。Webでも見れますし、書籍も出ています。

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

ユースケースを学ぶ、という意味でとても勉強になります。
50以上のデザインパターンがあり数は多いのですが、一つ一つのボリュームはそんなに多くないので、サクサク読めました。
知らないサービスもできてきますので、その時は調べながら進めました。

学習(4) ~各サービスについて知る~

AWS クラウドサービス活用資料集
ここに一番時間を割きました&とても勉強になりました。
各サービスの詳細な知識はここで補完しました。

EC2、ELB、Auto Scaling、
EBS、S3、RDS、DynamoDB、ElastiCache、
VPC、Route 53、
CloudWatch、CloudTrail、CloudFormation、
IAM、
SNS/SQS、
のサービスは何度も読みました。
また、上記のサービス以外については、AWS クラウドサービス活用資料集のページをざっとながめて、全然知らないサービスについては、概要とユースケースを確認するようにしました。

学習(5) ~活用事例やベストプラクティスを知る~

各サービスの知識はもちろん重要なのですが、AWSの考え方や実際の事例も重要です。

AWS クラウドサービス活用資料集の、以下の活用事例を読みました。

  • Web サービス StartUP 向け スケーラブルな構成例
  • AWS上の暗号化ソリューション
  • AWSにおけるセキュリティとコンプライアンス
  • AWS 上での DDoS 対策
  • クラウドのためのアーキテクチャ設計 -ベストプラクティス-

また、AWS Summitの資料も参考になりました。
AWS Summit Tokyo 2017 セッション資料・動画一覧
「AWS Well-Architected フレームワークによるクラウド ベスト プラクティス」など参考になります。

学習(6) ~ホワイトペーパーを読む~

AWS ホワイトペーパー
英語のものが多いのですが、日本語のものはいくつか読みました。
対策本を一度読んだあとにもいくつか読んだのですが、知らないサービスがあったり、知らない考え方があったりでなかなか読み進められませんでした。
各サービスについて知ったり、ベストプラクティスを知った後に読んだことでさくさく読めました。
ホワイトペーパーを読むことで知識を再確認したり、定着させることができたと思います。

学習(7) ~模擬試験~

模擬試験を受けることができます。
本試験と同じ操作をすることができるので、有料ですが、受験しておいたほうがよいと思います。
問題の雰囲気もつかめると思います。わからなかったところは復習しました。
アカウントを登録する必要がありますが、本試験でも必要になるアカウントです。
模擬試験の場合は、模擬試験の購入後、好きなタイミングで自分のパソコンで受験することができます。
時間、問題数ともに本試験より少ないです。

学習(番外編) ~有料セミナーやトレーニング~

私はArchitecting on AWSを受講しました。
最初に書いた「QwikLABS」も無料で受けられる範囲と有料で受けられる範囲とがあります。

前日

当日受験するテストセンターの場所と持ち物の確認をしました。

当日

最後に合格対策 AWS認定ソリューションアーキテクト – アソシエイトについている各章末問題をもう一度見直して、不安なところをググったりしていました。

学習法番外編 ~実家での勉強~

(大したことではないのですが・・・)
ちょうどお盆で実家に帰省する、した、という方も多いのではないでしょうか?
私も帰省後、東京に戻ってすぐ試験、という日程でした。
実家にいるとなかなか勉強できない!と思いましたので、

  • 友達と会う時間の2時間前に出かけて、外で勉強する
  • 家では寝る前等にさくっとこなせることをする(深く考えることは外で)
    • 問題といたり、クラウド活用集のスライドぱらぱらと見たり

最初はなかなか勉強できなさそうだし、どうしよう・・・と思っていましたが、思いのほか勉強できました。
やはり限られた時間で集中して行ったことがよかったと思います。
上記以外の時間は家族と出かけたりくっちゃべったり友達と会ったりと充実して過ごせたのではと思います。

いままで休日は「丸一日勉強するぞー」なんて意気込んで、結局集中できないことがたくさんありました(丸一日集中なんて無謀ですよね・・・)。
今後は丸一日勉強スタイルはやめようと思います。
思いもよらず、勉強のスタイルも見直すことができました。

続きを読む

CloudGarageの特徴と料金をAWSと比較

CloudGarageとは?

CloudGarage: https://cloudgarage.jp

CloudGarageはNHNテコラス株式会社が提供する定額型パブリッククラウドです。

特徴

  • 月単位の定額課金

    • プランはCPU/RAM/SSDのスペックとインスタンス上限数で決まる
    • 選んだプランに応じたスペックのインスタンスを上限数の範囲で自由に作成・削除できる
  • データ転送が無料・無制限(10Gbps共用・各インスタンスあたり1Gbps制限)
  • ロードバランサーも無料
  • DNSサーバは10ドメインまで無料

基本的には「VPSのような料金体系のクラウド」といった具合でしょうか。請求額はプランの金額から追加されるものがないので、非常にシンプルです。

AWSと比較

CPUやSSDのスペックが不明なので単純比較は難しいのですが、参考までにカタログスペックで簡単に見比べてみましょう。

CloudGarageの無料お試し枠の1GB/BOX3インスタンスは、CPUx1、RAM 1GB、SSD 50GBです。CPUx1、RAM 1GBは、AWSではt2.micro相当です(AWSの無料お試し枠でもある)。両者を比較してみます。

CloudGarage 1GB/BOX3 AWS t2.micro(northeast-1) オンデマンドインスタンス/Linux OSの場合
料金に関する詳細ページ CloudGarage AWS EC2
課金体系 月額固定 インスタンス稼働時間単位での課金
1インスタンスの料金(/h)1 0.66円 $0.016
(2017/08/10時点で約1.76円)
CPU 不明 詳細:T2インスタンスのCPUクレジットについて
バースト機能があり瞬間的なパフォーマンスは高い
インスタンスストレージ SSD 50GBが付属
性能は不明
インスタンスストレージなし(EBSが必須)
永続ボリューム なし EBSが最低1つ必要
汎用SSD50GBの場合 $6/Mo
固定IP なし(追加予定?) EIPが使用可能
インスタンスに関連付けられている場合は無料
ネットワーク料金 無料 インは例外を除いて無料、アウトは最初の1GBは無料で以後段階的にGB辺りの請求
データ転送 10Gbps共用・各インスタンスあたり1Gbps制限 共用ネットワーク(速度の保証なし)
ロードバランサー 無料 $0.027/実行時間+$0.008/GB
イメージ イメージ10個まで無料 保存先・データ量に依存(無料枠で済む場合もままあるが一概には言えない)
CLI API公開予定 CLI有り

なお、EC2にはリザーブドインスタンスというものがあり、1年または3年の契約をすることで料金が割引されます。期間や支払い方法にも依りますが、年間で40-60%ほど割引されます。詳細はこちらを見てください。

所感

ここからは個人の感想です。

料金体系が非常にシンプルで良い

AWSは請求額を算出するのがとにかくめんどくさいです・・・。CloudGarageの場合は月額固定で他に料金がかからないので見積もりが楽です。多くの場合1インスタンスだけってことはまずないでしょうし、最低でも3インスタンスの契約になるのはあまり気にはならない気がします。

「料金とかめんどくさいことを考えたくない個人の技術者」とかのニーズにすごく合っているのではないでしょうか。VPSっぽさがあります。

月単位での契約なので、常時稼働サーバは割安の可能性が高い

言うまでもないですが、AWSを含めた様々なクラウドベンダーのオンデマンドインスタンスをフル稼働するよりかなり安いです。t2.microですら1ヶ月フル稼働すると3500円くらいになります。1インスタンスで。

AWSのリザーブドインスタンスは最低でも年契約な上、途中でインスタンスタイプを変えられないクラスもあります。月単位での契約ですので途中でスケールしたくなっても対応しやすいですし、オンデマンドよりも安いので、ある程度要求スペックが安定しているような案件ではいい感じに使えるのではないでしょうか。

性能の詳細が分からない件

CPUやSSDがどういった性能なのか公式で言及されていません。

AWSにはストレージへの最適化インスタンスや、コンピューティングへ最適化されたインスタンスなど、様々なラインナップがあり、詳細なハードウェア要件を定めています。故に、要件に合わせて最適なインスタンスを選べます。要求がシビアな場合はCloudGarageよりもAWSの方がいいでしょう。

ただ、要求スペックとかなくてとりあえずCPUとSSDとメモリさえ最低限あれば細かいことを気にしない、というのなら関係ないです。少なくとも下手なレンタルサーバを借りてホームページ作るくらいなら1GB/BOX3の方が確実に安くて便利だと思います。

複合BOXが欲しい

超個人的な意見ですが、同じスペックのまとまりのBOXじゃなくて、BOX内のインスタンスごとにスペックを変えられたらいいなあと思いました。痒いところに手が届かない印象です。雑な例ですが、8GB/BOX10とかでサービス走らせてて、監視用のインスタンスを走らせたい時に、4Core/8GB/200GBとか要らんじゃないですか。かといって別途1GB/BOX3で新しくインスタンス借りるのもなあ・・・って感じです。

料金体系がシンプルな反面、柔軟性に乏しい感じです。

とりあえず試してみては?

1GB/BOX3が無料で試せるので、privateなgit鯖とか、VPNとか、余裕があればマイクロサービスでも構築してみたい感じです。


  1. 1ヶ月辺り31日で計算・税抜き 

続きを読む

[JAWS-UG CLI] Amazon Kinesis Firehose re:入門 (1) 事前準備(Source(Kinesis Agent)およびDestination(S3)の作成)

この記事について

JAWS-UG CLI専門支部 #90 Kinesis Firehose 復習編で実施するハンズオン用の手順書です。

前提条件

必要な権限

作業にあたっては、以下の権限を有したIAMユーザもしくはIAMロールを利用してください。

  • 以下のサービスに対するフルコントロール権限

    • Kinesis Firehose
    • IAM
    • EC2
    • S3
    • CloudWatch Logs
    • STS
    • (Lambda)
      • データの変換を行う場合
    • (KMS)
      • データの暗号化を行う場合

0. 準備

0.1. リージョンを指定

オレゴンリージョンで実施します。(東京マダー?)

コマンド
export AWS_DEFAULT_REGION="us-west-2"

0.2. 資格情報を確認

コマンド
aws configure list

インスタンスプロファイルを設定したEC2インスタンスでアクセスキーを設定せずに実行した場合、以下のようになります。

結果
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************QSAA         iam-role
secret_key     ****************c1xY         iam-role
    region                us-west-2              env    AWS_DEFAULT_REGION

0.3. バージョン確認

コマンド
aws --version
結果
aws-cli/1.11.129 Python/2.7.12 Linux/4.9.38-16.33.amzn1.x86_64 botocore/1.5.92

0.4. バージョンアップ(必要に応じて)

コマンド
sudo pip install -U awscli

1. 管理対象の構築

CloudFormationを利用して、Source(Kinesis AgentをインストールしたEC2インスタンス)とDestination(S3バケット)を作成します。

1.1. KeyPairの作成

EC2インスタンス用にKeyPairを作成します。

KeyPairの名前を指定

コマンド
AWS_ID=$(aws sts get-caller-identity 
    --query "Account" 
    --output text) 
    && echo ${AWS_ID}
コマンド
KEY_PAIR_NAME="${AWS_ID}_firehose_jawsug_cli"
KEY_MATERIAL_FILE_NAME=${KEY_PAIR_NAME}.pem

同名KeyPairの不存在を確認

コマンド
aws ec2 describe-key-pairs 
    --query "KeyPairs[?KeyName==`${KEY_PAIR_NAME}`]"
結果
[]

KeyPairの作成

コマンド
aws ec2 create-key-pair 
    --key-name ${KEY_PAIR_NAME} 
    --query "KeyMaterial" 
    --output text 
    > ~/.ssh/${KEY_MATERIAL_FILE_NAME} 
    && cat ~/.ssh/${KEY_MATERIAL_FILE_NAME}

KeyPairの存在を確認

コマンド
aws ec2 describe-key-pairs 
    --query "KeyPairs[?KeyName==`${KEY_PAIR_NAME}`]"
結果
[
    {
        "KeyName": "XXXXXXXXXXXX_firehose_jawsug_cli",
        "KeyFingerprint": "xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx"
    }
]

秘密鍵のPermissionを変更

コマンド
chmod 600 ~/.ssh/${KEY_MATERIAL_FILE_NAME}
ls -al ~/.ssh/${KEY_MATERIAL_FILE_NAME}
結果
-rw------- 1 ec2-user ec2-user 1671 Aug  5 18:33 /home/ec2-user/.ssh/788063364413_firehose_jawsug_cli.pem

1.2. CloudFormation テンプレートの生成

テンプレートの作成

コマンド
CF_TEMPLATE_FILE_NAME="firehose_jawsug_cli.yml"
コマンド
cat << EOF > ${CF_TEMPLATE_FILE_NAME}
AWSTemplateFormatVersion: "2010-09-09"
Description: JAWS-UG CLI Kinesis Firehose Hands-on

Parameters: 
  VPCNetworkAddress: 
    Type: String
    Description: "Network Address on AWS"
    MinLength: 9
    MaxLength: 18
    # AllowedPattern: "(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})"
    Default: "10.0.0.0/16"
  PublicSubnetAddr: 
    Type: String
    Description: "Network Address on AWS"
    MinLength: 9
    MaxLength: 18
    # AllowedPattern: "(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})"
    Default: "10.0.0.0/24"
  KeyPairName:
    Type: AWS::EC2::KeyPair::KeyName


Resources:
  S3Bucket: 
    Type: "AWS::S3::Bucket"
  IAMRole: 
    Type: "AWS::IAM::Role"
    Properties: 
      RoleName: "service-role-firehose"
      AssumeRolePolicyDocument: 
        Version: "2012-10-17"
        Statement: 
          - 
            Effect: "Allow"
            Principal: 
              Service: 
                - "firehose.amazonaws.com"
            Action: 
              - "sts:AssumeRole"
      Path: "/"
  IAMPolicy:
    Type: "AWS::IAM::Policy"
    Properties: 
      PolicyName: "service-policy-firehose"
      PolicyDocument: 
        Version: "2012-10-17"
        Statement: 
          - 
            Effect: "Allow"
            Action: 
              - "s3:AbortMultipartUpload"
              - "s3:GetBucketLocation"
              - "s3:GetObject"
              - "s3:ListBucket"
              - "s3:ListBucketMultipartUploads"
              - "s3:PutObject"
            Resource:
              - !GetAtt S3Bucket.Arn
              - Fn::Join: 
                - "/"
                - 
                  - !GetAtt S3Bucket.Arn
                  - "*"
          - 
            Effect: "Allow"
            Action: 
              - "logs:PutLogEvents"
            Resource: "*"
      Roles:
        - Ref: IAMRole

  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCNetworkAddress
      Tags: 
        - 
          Key: "Name"
          Value: "KinesisFirehoseClient"
  IGW:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags: 
        - 
          Key: "Name"
          Value: "KinesisFirehoseClient"
  AttachIGW:
      Type: AWS::EC2::VPCGatewayAttachment
      Properties:
          VpcId:
              Ref: VPC
          InternetGatewayId:
              Ref: IGW
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties: 
      AvailabilityZone: 
        Fn::Select: 
          - 0
          - Fn::GetAZs: ""
      CidrBlock: !Ref PublicSubnetAddr
      MapPublicIpOnLaunch: true
      VpcId: 
        Ref: VPC
      Tags: 
        - 
          Key: "Name"
          Value: "Public"
  PublicRT:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:
        Ref: VPC
      Tags: 
        - 
          Key: Name
          Value: Public
  PublicDefaultRoute:
    Type: AWS::EC2::Route
    Properties: 
      DestinationCidrBlock: "0.0.0.0/0"
      GatewayId: 
        Ref: IGW
      RouteTableId: 
        Ref: PublicRT
  PublicSubnetARouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId:
        Ref: PublicSubnet
      RouteTableId:
        Ref: PublicRT
  SecurityGroup:
    Type: "AWS::EC2::SecurityGroup"
    Properties: 
      GroupDescription: WebServer
      SecurityGroupEgress:
        - 
          IpProtocol: "-1"
          CidrIp: "0.0.0.0/0"
      SecurityGroupIngress:
        - 
          IpProtocol: "tcp"
          FromPort: 80
          ToPort: 80
          CidrIp: "0.0.0.0/0"        
        - 
          IpProtocol: "tcp"
          FromPort: 22
          ToPort: 22
          CidrIp: "0.0.0.0/0"
      VpcId:
        Ref: VPC    
  InstanceRole: 
    Type: "AWS::IAM::Role"
    Properties: 
      RoleName: "instance-role"
      AssumeRolePolicyDocument: 
        Version: "2012-10-17"
        Statement: 
          - 
            Effect: "Allow"
            Principal: 
              Service: 
                - "ec2.amazonaws.com"
                - "ssm.amazonaws.com"
            Action: 
              - "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns: 
        - "arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM"
        - "arn:aws:iam::aws:policy/AmazonKinesisFirehoseFullAccess"
  InstanceProfile: 
    Type: "AWS::IAM::InstanceProfile"
    Properties: 
      Path: "/"
      Roles: 
        - !Ref InstanceRole
  Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      KeyName: 
        Ref: KeyPairName
      ImageId: ami-6df1e514
      InstanceType: t2.micro
      SecurityGroupIds: 
        - Ref: SecurityGroup
      SubnetId:
        Ref: PublicSubnet
      IamInstanceProfile:
        Ref: InstanceProfile
      BlockDeviceMappings: 
        - DeviceName: "/dev/sdm"
          Ebs: 
            VolumeType: "gp2"
            DeleteOnTermination: "true"
            VolumeSize: "8"
      UserData:
        Fn::Base64: |
          #!/bin/bash
          cd /tmp
          sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
          sudo yum install -y aws-kinesis-agent
          sudo chkconfig aws-kinesis-agent on
          sudo service aws-kinesis-agent start
          sudo yum install -y httpd
          sudo chkconfig httpd on
          sudo service httpd start
          sudo yum install npm --enablerepo=epel -y
          sudo npm install -g jsonlint

Outputs:
  S3BucketName:
    Value:
      Ref: S3Bucket
  IAMRoleARN:
    Value: !GetAtt IAMRole.Arn
  PublicIP:
    Value: !GetAtt Instance.PublicIp
EOF

cat ${CF_TEMPLATE_FILE_NAME}

CloudFormation テンプレートの検証

コマンド
aws cloudformation validate-template 
    --template-body file://${CF_TEMPLATE_FILE_NAME}
結果
{
    "CapabilitiesReason": "The following resource(s) require capabilities: [AWS::IAM::InstanceProfile, AWS::IAM::Role]",
    "Description": "JAWS-UG CLI Kinesis Firehose Hands-on",
    "Parameters": [
        {
            "NoEcho": false,
            "ParameterKey": "KeyPairName"
        },
        {
            "DefaultValue": "10.0.0.0/16",
            "NoEcho": false,
            "Description": "Network Address on AWS",
            "ParameterKey": "VPCNetworkAddress"
        },
        {
            "DefaultValue": "10.0.0.0/24",
            "NoEcho": false,
            "Description": "Network Address on AWS",
            "ParameterKey": "PublicSubnetAddr"
        }
    ],
    "Capabilities": [
        "CAPABILITY_NAMED_IAM"
    ]
}

1.3. CloudFormation Stackの作成

CloudFormation Stack名の指定

コマンド
CF_STACK_NAME="firehose-jawsug-cli"

同名CloudFormation Stackの不存在を確認

コマンド
aws cloudformation describe-stacks 
    --query "Stacks[?StackName==`${CF_STACK_NAME}`]"
結果
[]

CloudFormation Stackの作成

コマンド
aws cloudformation create-stack 
    --stack-name ${CF_STACK_NAME} 
    --template-body file://${CF_TEMPLATE_FILE_NAME} 
    --capabilities "CAPABILITY_NAMED_IAM" 
    --parameters ParameterKey=KeyPairName,ParameterValue=${KEY_PAIR_NAME},UsePreviousValue=false
結果
{
    "StackId": "arn:aws:cloudformation:us-west-2:XXXXXXXXXXXX:stack/firehose-jawsug-cli/8812e540-7a0e-11e7-aac3-50a68d01a68d"
}

CloudFormation Stackの作成完了を待機

5分程度で作成が完了すると思います。

コマンド
aws cloudformation wait stack-create-complete 
    --stack-name ${CF_STACK_NAME}
結果
(返値無し)

CloudFormation Stackの存在を確認

“StackStatus”が”CREATE_COMPLETE”になっていることを確認します。

コマンド
aws cloudformation describe-stacks 
    --stack-name ${CF_STACK_NAME}
結果
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:us-west-2:XXXXXXXXXXXX:stack/firehose-jawsug-cli/4043bde0-7a16-11e7-8701-50a686be73ba",
            "Description": "JAWS-UG CLI Kinesis Firehose Hands-on",
            "Parameters": [
                {
                    "ParameterValue": "XXXXXXXXXXXX_firehose_jawsug_cli",
                    "ParameterKey": "KeyPairName"
                },
                {
                    "ParameterValue": "10.0.0.0/16",
                    "ParameterKey": "VPCNetworkAddress"
                },
                {
                    "ParameterValue": "10.0.0.0/24",
                    "ParameterKey": "PublicSubnetAddr"
                }
            ],
            "Tags": [],
            "Outputs": [
                {
                    "OutputKey": "PublicIP",
                    "OutputValue": "54.191.102.113"
                },
                {
                    "OutputKey": "IAMRoleARN",
                    "OutputValue": "arn:aws:iam::XXXXXXXXXXXX:role/service-role-firehose"
                },
                {
                    "OutputKey": "S3BucketName",
                    "OutputValue": "firehose-jawsug-cli-s3bucket-134czh3hcofqz"
                }
            ],
            "CreationTime": "2017-08-05T19:42:44.440Z",
            "Capabilities": [
                "CAPABILITY_NAMED_IAM"
            ],
            "StackName": "firehose-jawsug-cli",
            "NotificationARNs": [],
            "StackStatus": "CREATE_COMPLETE",
            "DisableRollback": false
        }
    ]
}

1.4. パラメータの確認

以降の手順で必要になるパラメータを抽出します。

  • IAMロールARN
  • S3バケット名
  • パブリックIPアドレス
コマンド
OUTPUTKEY_ROLE_ARN="IAMRoleARN"
OUTPUTKEY_BUCKET_NAME="S3BucketName"
OUTPUTKEY_PUBLIC_IP_ADDRESS="PublicIP"
コマンド
ROLE_ARN=$(aws cloudformation describe-stacks 
    --stack-name ${CF_STACK_NAME} 
    --query "Stacks[].Outputs[?OutputKey==`${OUTPUTKEY_ROLE_ARN}`].OutputValue[]" 
    --output text) 
    && echo ${ROLE_ARN}
結果
arn:aws:iam::XXXXXXXXXXXX:role/service-role-firehose
コマンド
BUCKET_NAME=$(aws cloudformation describe-stacks 
    --stack-name ${CF_STACK_NAME} 
    --query "Stacks[].Outputs[?OutputKey==`${OUTPUTKEY_BUCKET_NAME}`].OutputValue[]" 
    --output text) 
    && echo ${BUCKET_NAME}
結果
firehose-jawsug-cli-s3bucket-134czh3hcofqz
コマンド
PUBLIC_IP_ADDRESS=$(aws cloudformation describe-stacks 
    --stack-name ${CF_STACK_NAME} 
    --query "Stacks[].Outputs[?OutputKey==`${OUTPUTKEY_PUBLIC_IP_ADDRESS}`].OutputValue[]" 
    --output text) 
    && echo ${PUBLIC_IP_ADDRESS}
結果
54.191.***.***

動作確認

パブリックIPアドレスにブラウザでアクセスします。

以上

続きを読む

【AWS】AWS CLIでインスタンスの情報を抽出(InstanceID, VolumeID, SnapshotID)

はじめに

EC2インスタンスのスナップショットをスクリプトで取得しようとした際、下記情報をコマンドで取得する必要がありました。備忘録です。
※sedコマンドとかしていますが、ダブルクォーテーションを削除するためです。

①自分自身のインスタンスID
②自分自身のボリュームID
③自分自身のボリュームから取得したスナップショットID一覧
④自分自身のTAG(Name)

前提

  • AWS CLIがインストールされていること。
  • aws configureコマンド実行済み。
  • EC2FullAccessの権限を持った、IAMユーザーのアクセスキーとシークレットキーを取得済み。

①自分自身のインスタンスID取得

169.254.169.254にインスタンスのメタデータがあるらしいです。

curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en "n"

②自分自身のボリュームID取得

  • ${AWS_REGION}: リージョンを記載する。(例:ap-northeast-1)
  • ${INSTANCE_ID}: ①で取得したインスタンスIDを記載する。
aws ec2 describe-instances --region ${AWS_REGION} --instance-id ${INSTANCE_ID} --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs[]' | grep vol | sed 's/^.*"(.*)".*$/1/'

③自分自身のボリュームから取得したスナップショットID一覧取得

  • ${EBS_VOLUME_ID}: ②で取得したボリュームID
aws ec2 describe-snapshots --filters Name=volume-id,Values=${EBS_VOLUME_ID} | grep snap- | sed 's/^.*"(.*)".*$/1/'

④自分自身のTAG(Name)

  • ${AWS_REGION}: リージョンを記載する。(例:ap-northeast-1)
  • ${INSTANCE_ID}: ①で取得したインスタンスIDを記載する。
aws ec2 describe-instances --region ${AWS_REGION} --instance-id ${INSTANCE_ID} --query 'Reservations[].Instances[].Tags[].Value[]' | grep [0-9a-zA-Z] | sed 's/^.*"(.*)".*$/1/'

続きを読む

AWS節約術 4GiBのCentOS7ボリュームを作成

この記事ではAWS ec2上のCentOS7を使っています。

通常8GiB必要なCentOS7を、4GiBのボリュームで作成できるようにして、AWSの費用を削減しました。

なお、EC2 EBS縮小 (というより CentOS ディスク縮小) の流れを、大変参考にさせていただきました。

1. 背景

AWS ec2のインスタンスをたくさん作ると、EBSボリューム費用が莫迦にならなくなってきました。インスタンスそのものは、利用する時以外は落としておくことで、費用を節約することが可能です。一方、EBSボリュームは恒久的に利用しますので、ひと月の費用がまるまるかかってしまいます。

スクリーンショット 2017-07-31 21.21.10.png

こんな感じて、EBSの料金の比率が結構高いです。

CentOS7を使っていると、実際のディスク使用量は2GB〜3GBなのですが、最小のディスクサイズが8GiBであり、半分以上を無駄にしていることになります。Amazon Linuxであれば、最小2GiBからインスタンスが作れるのですが、やっぱりCentOSが使いたいですよね。

ボリュームを増やすことは、ec2のボリュームメニューから簡単にできるのですが、減らすことは簡単にできません。よって、小さいサイズで作っておいたほうが、使い回しが容易です。小は大を兼ねるのです。

ということで、4GiBボリュームでCentOS7が動作する環境を構築してみました。

2. 全体の流れ

全体の構成要素と流れは以下のようになります。

スクリーンショット 2017-07-31 22.19.20.png

3. 構築手順

3.1. 作業用インスタンスの作成

  • AWS MarketplaceからCentOS7を選択してインスタンス作成します。

    • 移行元用(ec2-old)、作業用(ec2-work)の2つを作成します。
    • 後の作業がやりやすいので、ボリュームにもインスタンスに対応するNameタグ(vol-old、vol-work)をつけておきます。
  • インスタンスを両方とも停止させます。
  • ec2のボリュームメニューで、vol-oldをデタッチします。
  • 移行先ボリューム(vol-new)を4GiBで新規作成します。
  • ec2-workに、vol-old、vol-newをアタッチします(デバイスIDはデフォルト値をそのまま利用します)。
  • ec2-workを起動してログインします。
$ sudo su -
# lsblk (確認)
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk 
└─xvdf1 202:81   0   8G  0 part 
xvdg    202:96   0   4G  0 disk 

3.2. 新ボリュームのパーティション作成とフォーマット

  • fdiskを使う例が多いのですが、ここでは非対話的にやりたいので、partedのコマンドラインでパーティションを作成し、フォーマットします。
# parted -s /dev/xvdg -- mklabel msdos mkpart primary xfs 1 -1 set 1 boot on
# parted -s /dev/xvdg print (確認)
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdg: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  4294MB  4293MB  primary               boot

# mkfs.xfs /dev/xvdg1
meta-data=/dev/xvdg1             isize=512    agcount=4, agsize=262016 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=1048064, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
  • マウントして結果を確認します。
# mkdir -p /mnt/old /mnt/new/boot
# mount -t xfs -o nouuid /dev/xvdf1 /mnt/old
# mount -t xfs -o nouuid /dev/xvdg1 /mnt/new
# lsblk (確認)
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk 
└─xvdf1 202:81   0   8G  0 part /mnt/old
xvdg    202:96   0   4G  0 disk 
# df -kT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs       8.0G  941M  7.1G  12% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
tmpfs          tmpfs     496M     0  496M   0% /dev/shm
tmpfs          tmpfs     496M   13M  483M   3% /run
tmpfs          tmpfs     496M     0  496M   0% /sys/fs/cgroup
tmpfs          tmpfs     100M     0  100M   0% /run/user/1000
tmpfs          tmpfs     100M     0  100M   0% /run/user/0
/dev/xvdf1     xfs       8.0G  941M  7.1G  12% /mnt/old
/dev/xvdg1     xfs       4.0G   33M  4.0G   1% /mnt/new

3.3. 新旧ボリュームのコピー

  • 新旧ボリュームをコピーして確認します。xvdg1の使用済みサイズがxvdf1と同じになったことがわかります。
# yum install xfsprogs xfsdump -y
(snip)
# cd /mnt/old/
# xfsdump -J - /mnt/old | xfsrestore -J -p 60 - /mnt/new
(snip)
xfsdump: Dump Status: SUCCESS
xfsrestore: restore complete: 17 seconds elapsed
xfsrestore: Restore Status: SUCCESS
# df -hT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     xfs       8.0G  1.1G  7.0G  13% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
tmpfs          tmpfs     496M     0  496M   0% /dev/shm
tmpfs          tmpfs     496M   13M  483M   3% /run
tmpfs          tmpfs     496M     0  496M   0% /sys/fs/cgroup
tmpfs          tmpfs     100M     0  100M   0% /run/user/1000
tmpfs          tmpfs     100M     0  100M   0% /run/user/0
/dev/xvdf1     xfs       8.0G  941M  7.1G  12% /mnt/old
/dev/xvdg1     xfs       4.0G  941M  3.1G  24% /mnt/new

3.4. ブートローダーのインストール

  • /mnt/new/ にチェンジルートします。
# mount -t proc /proc /mnt/new/proc
# mount -t sysfs /sys /mnt/new/sys
# mount --bind /dev /mnt/new/dev
# chroot /mnt/new/
# df -hT (確認)
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvdg1     xfs       4.0G  941M  3.1G  24% /
devtmpfs       devtmpfs  477M     0  477M   0% /dev
  • ブートローダーをインストールします。
# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-514.16.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-514.16.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-8bd05758fdfc1903174c9fcaf82b71ca
Found initrd image: /boot/initramfs-0-rescue-8bd05758fdfc1903174c9fcaf82b71ca.img
done
# grub2-install /dev/xvdg
Installing for i386-pc platform.
Installation finished. No error reported.
  • vol-newには新しいUUIDが付与されていますが、/etc/fstabはvol-oldからコピーしたため、不整合が残っています。UUIDを確認して、/etc/fstabの記述を正しいUUIDに修正します。
# blkid
/dev/xvda1: UUID="29342a0b-e20f-4676-9ecf-dfdf02ef6683" TYPE="xfs" 
/dev/xvdg1: UUID="96726bba-3ec0-4c18-a2d2-ef77f40c1837" TYPE="xfs" 
/dev/xvdf1: UUID="29342a0b-e20f-4676-9ecf-dfdf02ef6683" TYPE="xfs" 
# vi /etc/fstab (9672... に書き換える)
  • アンマウントしてシャットダウンします。
# exit
# cd /
# umount /mnt/old/ /mnt/new/proc /mnt/new/sys /mnt/new/dev /mnt/new/
# shutdown now

3.5. 新ボリュームでの起動確認

  • ec2-workから、vol-old、vol-newをデタッチします。
  • ec2-oldに、vol-newを/dev/sda1としてアタッチします。
  • 起動してログインできれば大成功!! 確かにファイルシステムのサイズが半減していますね。
$ df -kT (確認)
Filesystem     Type     1K-blocks   Used Available Use% Mounted on
/dev/xvda1     xfs        4182016 963300   3218716  24% /
devtmpfs       devtmpfs    487880      0    487880   0% /dev
tmpfs          tmpfs       507488      0    507488   0% /dev/shm
tmpfs          tmpfs       507488  12920    494568   3% /run
tmpfs          tmpfs       507488      0    507488   0% /sys/fs/cgroup
tmpfs          tmpfs       101500      0    101500   0% /run/user/1000
  • 作業に使ったec2-work、vol-work、vol-oldは削除してかまいません。
  • せっかく作ったインスタンスですので、ec2-old、vol-newの名前は適切に変更して、マイAMIとして登録しておきましょう。

続きを読む

AutoScaleを設定し、lambdaでAMIとAutoScaleの設定を自動更新する

今回はAuto Scaleの設定のまとめです。

・概要

負荷分散のためにAutoScaleを検討することはよくあることです。

ゲームのイベントなどでは負荷がかかる時間帯が決まっているので、常時起動しているサーバーを減らしAutoScaleのスケージュールで設定することで費用を抑えることが出来ます。

※AutoScaleは起動に時間がかかるので、スケーリングポリシーでは突発的な負荷に対応できないのでスケジュールを使っています。

・問題点

AutoScaleを設定した場合、設定しているAMIのassetやsourceが起動中のインスタンスと違うといった事が起こります。

そういった場合にAMIを更新し、自動的AutoScaleに割り当てる設定を行います。

・AutoScaleグループの作成

今回の設定は元々あるAutoScaleグループの設定を置き換えるので先にAutoScaleグループを作成しておきます。

・AWSコンソールの[AUTO SCALING]→[起動設定]→[起動の作成]

※ここの起動設定は最終的に使わないので適当でOKです

・AWSコンソールの[AUTO SCALING]→[AUTO SCALINGグループ]→[AUTO SCALINGグループの作成]

上記の起動設定を選択、下記を設定

ネットワーク
グループ名
ロードバランシング

※今回はスケジュールなのでスケーリングポリシーは設定しない
※通知を使用するとauto scaleの情報をlambda等に引き渡して色々出来ます。
※タグを使いauto scaleで作成されたインスタンスに適用できます。

※ここで作成したAUTO SCALINGグループの名前を控えておきます。

lambdaを設定

・[Blank Function]→リストから[CloudWatch Events]を選択
・ルール:新規のルール
・ルール名:任意
・ルール説明:任意
・ルールタイプ:スケジュール
・スケジュール式:cron(0 * * * ? *)
※cronの設定と同じ、上記は1時間毎
・トリガーの有効化にチェック

・名前:任意
・説明:任意
・ランタイム:python

・ロール:[カスタムロールの作成]を選択、IAMに下記をアタッチし作成、再度[既存のロールを選択]で作成したIAMを選択

・コード:下記を貼り付けて***の部分を自分の環境に置き換える

import boto3
import time
from botocore.client import ClientError
from datetime import datetime, timedelta, tzinfo
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)

ec2 = boto3.client('ec2')
autoscaling = boto3.client('autoscaling')

instance = "***" #コピー元のec2インスタンスID(例:i-22a9edc2ted27d2a1)
device_name = "***" #コピー元のec2のブロックデバイス(例:/dev/sda1)
image_prefix = "***" #amiの名前の識別子(任意※他のAMIで使っていない文字)
launch_prefix = "***" #auto scaleの起動設定の名前の識別子(任意※他の起動設定で使っていない文字)
ec2_volume_size = *** #ebsのボリュームサイズ(単位:GB)
ec2_volume_type = "***" #ebsのボリュームタイプ(例:gp2)
secrity_group = [***] #ec2インスタンスのセキュリティグループ
ec2_instance_type = "***", #ec2インスタンスタイプ(例:c4.2xlarge)
ec2_key_name = "***", #ec2インスタンスのキーペア名
auto_scaling_group_name ="***",#作成したAutoScaleGroup名


def lambda_handler(event, context):
    try:
        dstr = datetime.now().strftime('_%Y-%m-%d-%H-%M-%S_') + instance
        logger.warning("create ami:%s" % (dstr))
        new_ami = ec2.create_image(Name=image_prefix + dstr ,InstanceId=instance,NoReboot=True,DryRun=False)
        recv = ec2.describe_images(Owners=['self'])
        list=[]
        target = image_prefix
        for img in recv['Images']:
            if target in img['ImageLocation']:
                list.append(img)
        s_list = sorted(list,key=lambda h: h['CreationDate'])
        if len(s_list) > 0:
            del_target = s_list[0]
            logger.info("delete ami:%s" % (del_target['Name']))
            ec2.deregister_image(ImageId=del_target['ImageId'],DryRun= False)
        dstr = datetime.now().strftime('_%Y-%m-%d-%H-%M-%S')
        logger.info("create auto scale launch config:%s" % (dstr))
        device = {}
        device['DeviceName'] = device_name
        ebs = {}
        ebs['VolumeSize'] = ec2_volume_size
        ebs['VolumeType'] = ec2_volume_type
        ebs['DeleteOnTermination'] = True
        device['Ebs'] = ebs
        device_mapping = [device]
        launch_name = launch_prefix + dstr

        res = autoscaling.create_launch_configuration(
            LaunchConfigurationName = launch_name,
            ImageId = new_ami['ImageId'],
            InstanceType = ec2_instance_type,
            SecurityGroups = secrity_group, 
            KeyName = ec2_key_name,
            BlockDeviceMappings = device_mapping,
            AssociatePublicIpAddress = True
        );
        logger.info("update auto scale group name:%s" % (launch_name))
        res = autoscaling.update_auto_scaling_group(
            AutoScalingGroupName=auto_scaling_group_name 
            LaunchConfigurationName = launch_name
        );  
        target = launch_prefix
        recv = autoscaling.describe_launch_configurations()
        list=[]
        for launch in recv['LaunchConfigurations']:
            if target in launch['LaunchConfigurationName']:
                list.append(launch)
        s_list = sorted(list,key=lambda h: h['CreatedTime'])
        if len(s_list) > 2:
            del_target = s_list[0]
            logger.info("delete launch config:%s" % (del_target['LaunchConfigurationName']))
            autoscaling.delete_launch_configuration(
                LaunchConfigurationName=del_target['LaunchConfigurationName'],
            )
        logger.info("end ami update")

    except ClientError as e:
        logger.error( e )
    return 'end'

・auto scaleのスケジュールを登録する

負荷の時間に合わせて自由に

・注意事項

※最初はelbのhealthチェックだけじゃなくwebサーバーのログやawsコンソールで正常な起動を確認すること

※デプロイがAMIの更新と被らないようにすること

続きを読む

AWS EC2のスポットインスタンスでGPU版tensorflowを動かす

最近tensorflow使い始めました:smile: 手元のMacBook Proだと学習にとっても時間がかかるので、AWS EC2のGPUインスタンスを使ってみることに.
EC2を安価に使うにはスポットインスタンス♪と思ったのですが、なんと、スポットインスタンスだとCUDAとかがセットアップされたNVIDIAのAMIが選択できないじゃないですか:scream: どうやら素のOSの上に自力で環境構築しないといけないっぽい. でも1回環境作ってしまえば再利用は可能.

というわけで、GPU版tensorflowを動かすまでの手順をまとめます. 構築する環境は
Ubuntu 16.04 LTS + CUDA + cuDNN + python3.6 + tensorflow-gpu
です.

EC2インスタンスの作成

EC2コンソールから「スポットインスタンスのリクエスト」でインスタンスを作成します.

  • AMI: Ubuntu 16.04 LTS
  • インスタンスタイプ: p2.large
  • EBS ボリューム: デフォルト8GBなので適当に増やす. 32GBとか.

インスタンスタイプはp2.8xlargeやp2.16xlargeでもいいですが、セットアップはp2.largeで行っておいて、学習時に8xlargeや16xlargeに切り替えてもいいかも.

EC2インスタンスが起動したら各モジュールを最新版にアップグレードし、最低限の開発環境をインストール.

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install libffi-dev libssl-dev gcc make

pyenvを使ってpython環境を整える

まずpyenvをgit cloneする.

$ git clone https://github.com/yyuu/pyenv.git ~/.pyenv

.bashrc に以下追加.

PYENV_ROOT=$HOME/.pyenv
PATH=$PYENV_ROOT/bin:$PYENV_ROOT/shims:$PATH
eval "$(pyenv init -)"

編集した.bashrcを読み込んでおく.

$ source ~/.bashrc

続いてpythonのインストール. 今回はpython 3.6を入れる.

$ pyenv install --list|grep 3.6
  3.3.6
  3.6.0
  3.6-dev
  3.6.1
  3.6.2rc1
$ pyenv install 3.6.1
$ pyenv global 3.6.1
$ which pip3
/home/ubuntu/.pyenv/shims/pip3  # pyenvが使われているのを確認
$ pip3 install aws  # ついでに入れておく

CUDAのインストール

CUDAのダウンロードサイトでdebファイルのダウンロード先を調べる.

  • OS:Linux,
  • Architecture: x86_64,
  • Distribution:Ubuntu,
  • Version: 16.04,
  • Installer Type: dev(local)

を選べば良い. URLが分かったら, wgetで取得してインストール.

$ wget https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb
$ sudo dpkg -i cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb
$ sudo apt-get update
$ sudo apt-get install cuda

cuDNNのインストール

cuDNNのダウンロードサイトから cuDNN v6.0 Library for Linux を取得してインストールすれば良いのだが、ユーザ登録してログイン後のページからしかダウンロード出来ず、wgetでURL指定で簡単にダウンロード出来ない.
一度macに保存してscpでEC2に送り込むことにした.

# scpでローカルのMacからEC2にdevファイルをコピー. pemファイルのパスとIPは適宜変更.
$ scp -i aws.pem ~/Downloads/cudnn-8.0-linux-x64-v6.0.tgz ubuntu@12.34.56.789:~/
$ tar xzf cudnn-8.0-linux-x64-v6.0.tgz
$ sudo cp -a cuda/lib64/* /usr/local/lib/
$ sudo cp -a cuda/include/* /usr/local/include/
$ sudo ldconfig

tensorflowのインストール

CPU版のtensorflowが入っている場合はuninstallしてからGPU版を入れる. ついでによく使うライブラリも入れておく.

$ sudo apt-get install libcupti-dev
$ pip3 uninstall tensorflow
$ pip3 install tensorflow-gpu
$ pip3 install keras sklearn matplotlib scipy librosa

サンプルを動かして動作確認

今回はkerasのmnist-mlpで動作確認. git cloneでサンプルを取得して実行.

$ git clone https://github.com/fchollet/keras.git
$ cd keras/examples
$ $ python mnist_mlp.py 
Using TensorFlow backend.
...
Test loss: 0.118156189926
Test accuracy: 0.9811
$

動いた:sunglasses:

続きを読む