AmazonECRとEC2を使って手元でビルドしたDockerイメージをAWS上でサクッと動かす

ECR(EC2 Container Registry)に登録したDockerイメージをEC2上でコンテナとして起動するまでの一通りの流れを書いてみた
ECSも一通り検証終わっていて、サービスではそちらを使う予定だが、基礎を振り返るという意味でのまとめ。

Docker

ここ一ヶ月ひたすらdockerを触っているが、やはり手元の開発環境で動いたものが、別の環境でそのまま動くというのは他にないメリット。
これまでだと、開発環境でOK→STでまた一から作る→本番でも同じくみたいなことしてたけど、ホスト側にDockerエンジン入れるだけで、実際のプロセスは開発環境のものをそのまま移植出来るというところはかなり熱い。といった印象。

やること

  • ECRを使う準備
  • ECRへのDockerイメージの登録
  • EC2作成
  • EC2上にECRからpullしたDockerコンテナを立てる

ECRとは

正式名称 EC2 Container Registry
Amazonが提供するフルマネージドのDockerコンテナレジストリ。
Dockerイメージを管理して、ECS(EC2 Container Service)やEB(Elastic Beanstalk)に簡単にデプロイすることが出来るソリューション

ECR使うと何がうれしい

  • EC2インスタンスにIAMroleを付与するだけ、EC2側で面倒な認証をせずにdockerイメージを使える
  • S3がバックエンドなので、可用性高い
  • 自動的に暗号化されたり、https通信されるのでセキュリティも安心

ECRを使う準備(ローカルマシンで実施)

AWS Command Line Interface のインストール を参考にAWS CLIを手元のマシンにインストールしておく。

基本的には、AWS CLIで操作する。

1.リポジトリの作成&確認

$aws ecr create-repository --repository-name tst-shnagai
{
    "repository": {
        "registryId": "xxxxx",
        "repositoryName": "tst-shnagai",
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxx:repository/tst-shnagai",
        "createdAt": 1496229520.0,
        "repositoryUri": "xxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai"
    }
}

リポジトリは、GUIから見ると、ECSサービスの中の[リポジトリ]に出来る

Amazon_EC2_Container_Service.png

2.ecrにログイン

セッションは12時間なので、感覚的に翌日には切れてる感じ。

## これで一発

$ $(aws ecr get-login --region ap-northeast-1)
Flag --email has been deprecated, will be removed in 17.06.
Login Succeeded

## $()の式展開を使わない場合

$ aws ecr get-login --region ap-northeast-1
docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
### 標準出力の結果を貼り付けてログイン
$ docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
Login Succeeded

ECRへのDockerイメージの登録(ローカルマシンで実施)

手元にある何かしらのDockerイメージをECRにpushする手順
手元で、Dockerイメージに対して、ECR用のタグづけを行ってから、ECRにpushする

1.docker tagコマンドでタグづけをする

今回は例として元々手元にある[apache_td]というdockerイメージに対して、ECRのルールに沿った名前でタグ付け(aliasつけるようなもの)する

## 元々のイメージ
$ docker image list |grep apache_td
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

## タグ付けを実施
$ docker tag apache_td:latest  xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## imageIDは変わらないので、下記のような検索するとapache_tdがECRに対応したイメージとしてタグ付けされたことがわかる
$ docker image list |grep 2c42dd
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai     latest              2c42dd3f5e5c        13 days ago         1.4GB
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

2. 1でタグづけしたDockerImageをECRにpushする

$ docker push xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
The push refers to a repository [xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai]
47d1cbb6b480: Layer already exists
...
latest: digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1 size: 2411

GUIで、タグ名とプッシュされた日時を確認して無事イメージがアップされていることを確認する

Amazon_EC2_Container_Service.png

ここまでで、ECRへのDockerイメージの登録は完了!!

EC2インスタンスの作成

1.通常通りEC2インスタンスを作成する(OSはデフォルトでawscliが入っているamazon linuxだと楽)

ポイントは、IAMRoleに[AmazonEC2ContainerRegistryReadOnly]ポリシを付与しておくことのみ

IAM_Management_Console.png

2. dockerのインストール

AWSの公式ドキュメントに沿ってやるだけなので、コマンドだけ羅列
Docker のインストール

ec2-userでdockerコマンドがsudoなしでうてるとこまでやっておく。

$ sudo yum update -y
$ sudo yum install -y docker
$ sudo service docker start
### ec2-userでsudoなしでdockerコマンドを打てるようにするため
$ sudo usermod -a -G docker ec2-user
###再ログイン
$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce

EC2上にECRからpullしたDockerコンテナを立てる(EC2上で実施)

1. ECRへのログイン

IAMRoleがついていない場合は、ログインで弾かれる

$ $(aws ecr get-login --region ap-northeast-1)
Login Succeeded

2. ECRからDockerイメージをpullする

## ECRにアップロードしたイメージをpull
$ docker pull xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
latest: Pulling from tst-shnagai
996fe98f55d8: Pull complete
...
e6b377ddca6e: Pull complete
Digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1
Status: Downloaded newer image for xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## 手元のイメージとして登録されたことを確認
$ docker image ls
REPOSITORY                                                      TAG                 IMAGE ID            CREATED             SIZE
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai   latest              2c42dd3f5e5c        13 days ago         1.4 GB

3. dockerコンテナを起動する

pullしてきたイメージからコンテナを起動する

## ホストの8080ポートにマッピングするtestという名前のコンテナを起動する
$ docker run -d --name test -p 8080:80 xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
dbbb74b6ebe95666d356250de8310c19403078f53e020069e9a6d10e479b2873

## -lオプションで最後に起動したコンテナを表示
$ docker ps -l
CONTAINER ID        IMAGE                                                                  COMMAND                  CREATED             STATUS              PORTS                  NAMES
dbbb74b6ebe9        xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest   "/bin/sh -c '/bin/..."   4 seconds ago       Up 4 seconds        0.0.0.0:8080->80/tcp   test

## 動作確認として、ホストの8080に対してcurlでリクエストしてみる
$ curl localhost:8080
version 1.2

まとめ

オーソドックスな、AWSでECRを使ってdockerコンテナを起動する一通りの流れをやってみた。dockerを手元で触ってる人だったら、特に躓くことなくやれる内容だと思う。
ECSは、基本オペレーション(この投稿でいうEC2以降の話)を抽象化して、クラスタというEC2集合体の上で、ELB,AutoScaling等を付加して使えるサービスなので、ココら辺をちゃんと理解してやるとやらないでは進みがだいぶ違うという印象を受ける。
裏で何が行われてるのかなという道理を理解することは大事。

続きを読む

AWS ECSを使用する前にDockerを理解しなきゃ

◎はじめに

・Amazon EC2 Container Service (ECS)ってなんじゃらほい?
というわけでざっくり調べてみたところ、Dockerコンテナを管理するものとのこと。
『えっ、、Dockerってクジラさんのアイコンのヤツでしょ。VMの一つの。。』
とまたまたITリテラシーの低さを露呈した私、
ECSを触る前にまずDockerを理解する必要が出てきました。

1. Dockerとは

docker.png

Wikipediaより

Docker(ドッカー)はソフトウェアコンテナ内のアプリケーションのデプロイメントを自動化するオープンソースソフトウェアである。
Linuxカーネルにおける「libcontainer」と呼ばれるLinuxコンテナ技術とaufsのような特殊なファイルシステムを利用してコンテナ型の仮想化を行う。

はい。まだよくわかりません。。コンテナってなんなのさ。。。

1-1. コンテナとは

■目的
・デプロイ作業を簡易にする
→ 開発環境をそのまま本番環境として利用できる
→ アプリケーション開発環境(ライブラリ、環境変数など)をまるごとパッケージングし本番環境にデプロイすることで環境に依存することがなくなる。

■仮想化との差異

タイプ    概要
仮想化 複数のオペレーティングシステムが単一のシステム(ゲストOS)で同時に実行できるようになる
コンテナ 同じオペレーティング・システム・カーネルを共有し、アプリケーションプロセスをシステムの他の部分から独立させる

▽補足
・Hypervisor上に複数のOSを実行する仮想化は負荷が大きい。
一方、コンテナはホストOS、ライブラリを共有している。
そのため少ディスクかつ少メモリでビルドもデプロイも高速、オーバーヘッドも少ない。
それでいて仮想化のためプラットフォームやハードウェアからは隔離された環境となっている。

・1コンテナ=1プロセス

▽参考サイト:
今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2

1-2. 取り敢えず触ってみよう

■参考サイト
・公式サイト
https://docs.docker.com/

・Docker ドキュメント日本語化プロジェクト
http://docs.docker.jp/index.html

■環境
・最新のAmazon linux AMIからlaunchしたインスタンスに導入してみました。

[ec2-user@mitzi_dev02 ~]$ uname -r
4.9.27-14.31.amzn1.x86_64

■余談
・amzn linuxへのインストール方法が公式サイト上で見つからなかったため、CentOSの手順でやってみたところ
ライブラリが足りないなどのエラーが多発し撃沈。。そこで上述の日本語化されたサイトを見たところAWS公式DocumentationのECSの項にDockerの説明・導入方法の記載がありました。親切ね

Docker の基本

■インストールそしてHello World

・パッケージとパッケージキャッシュを更新
$ sudo yum update -y

・Dockerをインストール
$ sudo yum install -y docker

・Dockerサービスを開始する
$ sudo service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:  .                                  [  OK  ]

・ Dokerの環境情報表示でコマンド実行できることを確認
$ sudo docker info
・Hell world コンテナを実行

[ec2-user@mitzi_dev02 ~]$ docker run ubuntu:14.04 /bin/echo 'Hello world'

docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.27/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
[ec2-user@mitzi_dev02 ~]$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'
Unable to find image 'ubuntu:14.04' locally
14.04: Pulling from library/ubuntu
1d8592394ba1: Pull complete
01aa7f61ccd1: Pull complete
5dd2552a960e: Pull complete
7cbe941c5e3e: Pull complete
2549ecfb14c6: Pull complete
Digest: sha256:30204139c6ab96ebd75d72f34db390f28c4decd5e563488b4e485bf979397b67
Status: Downloaded newer image for ubuntu:14.04
Hello world

公式サイトより、ここでやっていることの説明を引用

  • docker run でコンテナを実行。
  • ubuntu は実行するイメージです。この例では Ubuntu オペレーティング・システムのイメージです。イメージを指定したら、Docker はまずホスト上にイメージがあるかどうか確認します。イメージがローカルに存在していなければ、パブリック・イメージ・レジストリである Docker Hub からイメージを取得(pull)します。
  • /bin/echo は新しいコンテナ内で実行するコマンドです。

コンテナを起動するとは、Docker が新しい Ubuntu 環境を作成し、その中で /bin/echo コマンドを実行し、その結果を出力します。

なんとなくイメージが湧いてきました。
ここでは簡単なコマンドを実行しただけですが、これを応用していくことで前述の目的を達成するんだろうな。という何となくなイメージが

とりあえず今回はココまでになります。
引き続きDockerを触ってゆき、その先にあるECSを使いこなせるようにしていきたく思います。

続きを読む

略称がややこしいサービス in AWS

随時更新予定

改めて、Elasticって何?

AWSを使ってるとやたらと目にするので改めてElasticの意味を

  • 形容詞

    1. 弾力のある、しなやかな
    2. 〈人・感情など〉不幸があってもすぐ立ち直る,容易に屈しない; 屈託のない.
    3. 融通性のある
  • 名詞
    1. ゴムひも,ゴム入り生地.
    2. 可算名詞 《主に米国で用いられる》 輪ゴム.

Weblioより

恐らくAWSとしては「融通性のある」という意味合いで使ってるっぽい

EC2とECSとECR

EC2

  • 正式名: Elastic Compute Cloud
  • 何の変哲もない仮想サーバ
  • サーバレス界隈では「EC2を使っていいのは小学生まで」と言われているらしい

ECS

  • 正式名: EC2 Container Service
  • 略称であるEC2の頭文字をとるという荒業
  • Dockerをよしなに扱えるEC2と思えばだいたい合ってる

ECR

  • 正式名: EC2 Container Registry
  • AWS内に作れるプライベートなDockerイメージリポジトリ
  • 位置づけ的にはECSの諸々の機能の中にECRが存在する
  • なのでAWSコンソールのサービス名検索では現れない

EBとEBS

EB

  • 正式名: Elastic Beanstalk
  • EC2やロードバランサをまとめて管理するツール
  • 設定ファイルを使いまわせばすぐに環境を構築できる
  • あまり使われてないっぽいけど意外と便利

EBS

  • 正式名: Elastic Block Store
  • EC2にマウントするストレージボリューム
  • 後から拡張しようとすると地味にめんどくさい

RDSとRDB

RDS

  • 正式名称: Relational Database Service
  • (オンプレよりは)運用しやすいデータベース
  • とはいえフルマネージドではないのでサーバレス界隈では嫌われている
    • Lambdaからつなぎに行くと同時接続数制限で死ぬのが不評

RDB

  • 正式名称: Relational DataBase
  • サービスでなく一般名詞
  • RDSと字面も意味もダダ被りなので混ざりやすい
    • しかも言い間違えたりしても問題ない場面が多かったりする

SQS、SNS、SES、SMS

SQS

  • 正式名称: Simple Queue Service
  • キューを放り込むためのもの
  • 複数サービス連携しつつ、処理が確実に行われる保証が欲しいってときにお世話になる

SNS

  • 正式名称: Simple Notification Service
  • なんらかの方法で通知を送るためのサービス
  • 「SNS」だけだとSocial Networking Serviceのことだと誤解されるかもしれないので注意
  • 「SNSの機能でSMSを使える」とだけ言うとまるでfacebookからメッセージを送れるという話のようだ
    • 翻訳すると「Simple Notification Serviceの機能で携帯電話にショートメッセージを送れる」

SES

  • 正式名称: Simple Email Service
  • メールの送受信サービス
  • 初期状態ではサンドボックスに閉じられてるので、サポートに「がっつり使わせて」という申請が必要です。

SMS

  • 正式名称: Server Migration Service
  • オンプレのサーバをAWSに移行するサービス
  • ここでもう一度「SNSの機能でSMSを使える」というフレーズを思い出してほしい
    • もはや何を言っているかわからない

最近の動向

サービスの種類が増えてきたからか最近は略称を使わない方向に行ってるっぽい
とはいえ、略称を使うことは多いのでちゃんと相手と文脈を共有したうえで適宜補足をしましょう

続きを読む

AWS Summit Tokyo 2017 参加レポート Day3 (6/1)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月1日(Day3)に聴講した内容をレポートします。(Day4のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


基調講演(Key Note) (10:00 ~ 11:30)

ホストトーク:オープニング

by Werner Vogels 氏 (Amazon.com CTO)

  • AWSは急速に成長している

    • 成長率はIT企業の中でもTOP
    • 毎月のユーザー増加数 = 日本では10万以上
    • 各国のリージョン、AZ、エッジロケーションも随時拡大中
  • 本イベントを通してAWSを色々学んで行って欲しい。

気になったワードメモ

  • AWS Activate
  • One Amazon
  • Osaka リージョン開始

ゲストトーク:株式会社ソラコム

by 安川 健太 氏 (株式会社ソラコム 最高技術責任者)

SORACOMのサービス展開

IoTはネットワークセキュリティが課題
>3G/LTE網でInternetに出ないIoTネットワーク(デバイスとクラウドの直接接続)を提供

SORACOM Funnel
>デバイスからクラウドへのデータ転送を疎結合に管理
 利用例:デバイス>Funnel>Kinesis>Lambda>AWS IoT
  ⇒Funnelから先の切り替え(=新サービス追加など)が容易

ホストトーク:AWS – SUPER POWERS 1

by Werner Vogels 氏 (Amazon.com CTO)

「AWSは開発者に『SUPER POWERS※』を与える。」 (※ネタ元:スーパーマン)

SUPER POWER – ‘SPEED’ (超音速)

  • EC2新インスタンス:F1(FPGA利用可)
  • 今の時代 検索は必須>Elastic Search等ですぐに実装可
  • CloudはInfraへの関心を省き、Productに集中させてくれる>開発を加速
  • AWSは色々な選択肢を提供>ビジネスに合わせて適切なものを

ゲストトーク:NTT東日本

by 中村 浩 氏 (東日本電信電話株式会社 取締役)

CloudGateway re:connect
>FLETS光の高速・閉域網でAWSと再接続

社内で開発・利用して便利だったものを社外にも利用してほしい
クラウドと企業間の距離が一番近い国に

ホストトーク:AWS – SUPER POWERS 2

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘INVISIBILITY’ (目に見えない)

⇒開発者がインフラを気にしなくていい ⇒サーバーレス機能群紹介

  • AWS Lambda

    • サーバーレスコンピュート
  • AWS Step Functions
    • ビジュアルワークフローで分散アプリケーションのコンポーネント管理
  • AWS X-Ray
    • 分散アプリケーションの分析とデバッグ
  • Amazon DynamoDB Accelerator(DAX) :new:
    • 完全マネージド型インメモリキャッシュクラスタでクエリ超高速化

ゲストトーク:ソニーモバイルコミュニケーションズ

by 川西 泉 氏 (ソニーモバイルコミュニケーションズ株式会社 取締役 EVP)

SonyモバイルのIoTへの取り組み:『カーリングビジネスの実現』

製品紹介
– XPERIA Ear
– XPERIA Touch
– XPERIA Agent
  >http://av.watch.impress.co.jp/docs/news/1018278.html

スマートホームシステム
 AWS IoTを活用
 製品例:自宅のLED照明>センサーで子供の帰宅感知>仕事(外出)中の親に通知>LED付属のスピーカで会話

ホストトーク:AWS – SUPER POWERS 3

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘FLIGHT’ (飛び立つ)

IoTデバイスはサーバを必要としない

  • AWS Greengrass
     ⇒サーバ側の役目だった処理をローカルで構築可能に

これまでのデータベース=実機やベンダー由来の様々な制約や障害があった
クラウド+オープンソースのDBで”制約”から飛び立とう

  • AWS Database Migration Service
  • Amazon Aurora
    • 完全MySQL互換のRDB
    • PostgreSQL互換も提供開始

ゲストトーク:グリー株式会社

by 藤本 真樹 氏 (グリー株式会社 開発・人事統括 取締役 執行役員常務 CTO)

オンプレで10年運用してきた環境をクラウドへ移行した話

技術選択の判断は難しい、基準には色々な軸がある
敢えて上げるならば、”is that faster?”
>速さは裏切らない(コンピュータが速くて困ることは絶対にない)

⇒ AWS(の機能やサービス展開速度)はこれらに応えられる

ホストトーク:AWS – SUPER POWERS 4

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘X-RAY VISION’ (透視)

⇒ データの集計・可視化

  • Amazon Athena

    • S3に保存されたデータを標準SQLで簡単に分析
  • Amazon EMR
    • Hadoopなどのビッグデータフレームワークを手軽に実行・分析可能
  • Amazon Redshift
    • 複雑なクエリ・超高速パフォーマンスを提供するペタバイト級データウェアハウス
  • Amazon Redshift Spectrum :new:
    • S3のデータを直接クエリ可能
    • エクサバイト規模のクエリ>Hiveで5年想定の処理を155秒で完了

SUPER POWER – ‘PRECOGNITION’ (予見)

⇒ Amazon AI – 人工知能サービス

  • Amazon Machine Learning

    • カスタム予測モデルの学習
  • Amazon Rekognition
    • 画像から顔と感情を認識
  • Amazon Polly
    • 文章をリアルな音声に変換(感情付加など)
  • Amazon Lex
    • 自動音声認識・自然言語理解

SUPER POWER – ‘IMMORTALITY’ (不朽)

⇒ スタートアップ企業生き残りの鍵 =『デジタルトランスフォーメーション』

AWSは『イノベーション』を続ける


AWS 認定試験 (12:30 ~ 13:50)

Summit特設会場でソリューションアーキテクトアソシエイト試験を受験(特典の50%OFFクーポン目当てです ^^; )

試験終了後すぐに認定者限定ラウンジに行ってみましたが、ノベルティの折り畳み傘はとっくに品切れでした;;
やはり一日数量限定は午前中に行かないと無理な模様。( ⇒ Day4で無事GET!!)

限定ラウンジではお菓子や飲み物が無料、座ってPCなどの充電が出来て中々快適でした。
モニタなど設置して講演中のセッションを視聴できればいいなと考えましたが、逆に人が溢れて寛げなくなりそう?


Session:『AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション』 (14:20 ~ 15:00)

スピーカー:Prasad Kalyanaraman 氏 (Vice President, AWS Edge Services)

セッション概要(タイトルリンク先より引用)

AWS Edge Services では、Amazon CloudFront に加え、AWS Shield、 AWS Lambda@Edge などの革新的な新サービスを発表しています。本セッションでは、AWS Shield の DDoS 防御機能と、AWS Lambda@Edge の CDN 上でのスクリプト実行により、セキュリティを担保しつつ柔軟でカスタマイズ性の高いアプリケーションの実現方法をご紹介します。

エッジでのセキュリティ活用

セキュアコンテンツ配信にCloudFrontが使える
 >エンドユーザー付近をセキュア通信の終端にする

Lambda@Edge

=Lambda関数のデリバリーサービス
 ・Bot 判定
 ・バリデーション
 ・認証処理
  ⇒エンドユーザ付近で実行できる
 ・ユーザ毎にコンテンツカスタマイズ可能
  e.g.
   ・PC/モバイル判定>アクセス先分岐
   ・エッジでHSTSヘッダを埋込み

DDoS対策 (スクラビングセンター)

 >AWS Shield (全Edgeロケーションで使用可)
  >Standard
   ・エッジで攻撃を検知し、遮断
   ・リアルタイムで悪意のあるトラフィックを検出
   ・無料で自動適用
  >Advanced
   ・攻撃データの可視化、およびイベント後の分析と調査を容易に
   ・DDoS攻撃で請求金額が跳ね上がるのを防ぐ「DDoS コスト保護」
   ・専門サポート
   ・有料

AWS WAF

 >L7(アプリケーションレイヤー)防御
 >Lambdaで独自のセキュリティチェック可 (e.g. 特定のIPを一定時間ブロック等)


Session:『Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム』 (15:20 ~ 16:00)

スピーカー:松田 和樹 氏 (株式会社インティメート・マージャー 開発本部)

セッション概要(タイトルリンク先より引用)

インティメート・マージャーではビジネスの都合上、50 種類ものジョブワーカーを運用しております。増え続けるビジネス要件に対応するため、Amazon ECS と SpotFleet を軸に Amazon S3、Amazon SQS、Autoscaling を組み合わせることで、低コストかつスケーラブルな docker 基盤を構築致しました。本セッションでは、その docker 基盤を中心にお話しします。

公演に使用されたスライドが公開されてます。

構築背景

  • 20以上の社外システムとデータ受渡し

    • 異なるデータ形式
    • 異なる接続方式
  • データ肥大化
    • スケールする仕組みが必要
    • 特定のジョブのみスケールさせたい

第一世代

処理フロー

S3ファイルUP>イベントをSQS通知>Cloud Watchでキュー数監視>EC2のワーカーをAutoScaling (Spot)
 >SQSキュー&S3ファイルを取得し処理>後続処理は別のS3へ

課題

  • スポット高騰時など特定のワーカーが起動不可となる
  • リソース(InstanceType)効率が悪い
  • 待機時間が長い
  • スケーリング設定多く、運用負荷高い

第二世代

変更点

  • 全ワーカーの実行環境をコンテナに
  • docker基盤共用
  • ECS採用
  • spot fleet採用
  • ワーカー毎にコンテナをスケール

Amazon ECS

  • 52のサービスが稼働 ( 50種のワーカー + Mackerel(監視) + Fluentd(ログコレクタ) )
  • コンテナレジストリ ⇒ Amazon ECR

Spot fleet

  • 168 vCPU
  • 自動入札(一つ一つ設定も可能だが手間)
  • InstanceType:7種 主にC4、M4系

運用のポイント

ログのハンドリング

  • 目的で集約先使い分け

    • 常時監視 ⇒logdna
    • 長期分析 ⇒BigQuery
    • 直近データ分析、参照 ⇒Aurora

環境構築・デプロイ

  • Terraform採用
  • CircleCIからAPIでデプロイ
     ⇒docker対応CIサービスがおすすめ

強制ターミネート(Spotインスタンス)

  • コンテナ強制終了
  • 検知する仕組み必要
    • メタデータをポーリング⇒クラスタから退役

AMI

  • ECS-Optimized AMI 使用
  • AMIのカスタマイズはしない
  • 設定はcloud-initで

ECSの課題

  • クラスタ管理

    • agent方式⇒ラグが多々
    • ゾンビワーカー
  • docker全機能は使えない
  • コンソール画面がまだまだ
  • 学習コストそこそこ

ECSの強みは他AWSサービスとの連携


Session:『AWS で実現するセキュリティ・オートメーション』 (16:20 ~ 17:00)

スピーカー:桐山 隼人 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか?

※スライドは公開されていないようですが、ほぼこれと同じだったかと思います。

クラウド移行に関するアンケート

日:クラウドに移行しない理由 1位 ⇒セキュリティ
米:クラウドに移行した理由 1位 ⇒セキュリティ
 ⇒まだ正確な認識が普及していないせいと思われる

クラウドだからできるセキュリティ

オートメーションとは=戦略策定の基盤
AWSはセキュリティオートメーション前提に設計されている ⇒基盤として活用してほしい

  • 戦略策定

    • SFA、マーケティングに活用
    • やること やらないこと を決められる
  • 何を自動化すべきか? (考える主軸 ⇒)

    • 対策主体(人、組織、技術)
    • 対策対象(サーバ、ネットワーク、クライアント)
    • 対策場所(入口、内部、出口)

ガートナーの『適応型セキュリティアーキテクチャ』

サイクルを回す:
 防御⇒検知⇒対応⇒予測⇒~

 防御:CloudFront、WAF ~
 検知:VPC Logs、Auto Scaling ~
 対応:SNS、Lambda ~
 予測:EC2 Config、3rd party レピュテーション、Inspector ~

実用例

CloudFrontアクセス⇒WAF⇒LambdaでレピュテーションリストDL&判定
 ⇒Lambdaでセキュリティ評価⇒Amazon Inspector⇒SNS⇒LambdaでNACL/SG変更
 ⇒攻撃検知⇒ブロックログ⇒EBSなどsnapshot⇒CloudTrail(操作ログ)
全レイヤー、ノードのログが取れるので
 ⇒VPC Flow Logs/Elastic Search/Kibanaなどで可視化
攻撃者のドメイン生成は自動化されている:Domain Generation Algorithm(DGA)
 ⇒AWS WAF + Amazon MLで怪しいドメインを学習
Machine Learningでリスク分析
 ⇒設定変更などの意思決定まで自動化


Session:『Machine Learning on AWS』 (17:20 ~ 18:00)

スピーカー:志村 誠 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。

どんなサービスで機械学習を活用するか?

ビジネス主体で考える(使いたい技術から考えない)

  • 良質なデータが継続的に入るか
  • 自動化の価値ある予測か
  • 費用対効果

機械学習はあくまでツール
需要に反し解決していない問題に対して検討する

代表的な活用例>
– レコメンド
– 異常検知
– 画像認識
– クラスタリング(ユーザの分類分けなど)

AWSで提供する機械学習サービス

グルーピング>

  • Service
  • platform
  • Engines
  • Hardware

AI Hardware

  • EC2:P2 instance

    • GPU特化
  • Greengrass
    • デバイスに学習モデル
    • エッジで推論処理

AI Engines

典型的な機械学習フレームワークをインストール済みのAMIを提供

AI platform

  • Amazon Machine Learning
  • Amazon EMR

AI Service

  • Polly
  • Rekognition
  • Lex

その他

Kinesis Analytics >異常検知
Elastic Search >検索を機械学習に利用
Data Pipeline >EMRのジョブをスケジューリング

ゴールを明確に

  • 解決すべき課題
  • アウトプット

続き⇒Day4

続きを読む

【レポート】AWS Summit Tokyo 2017:C# 開発者必見、Docker コンテナへの継続的デプロイメント on AWS ~CodeCommit, CodeBuild, CodePipeline, CloudFormation, ECR, ECS を活用した CI/CD ~ #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。 当エントリでは […] 続きを読む

AWS ECSにてカスタムしたredmineのdockerイメージを動かすまでのメモ(その2)

前回の記事(http://qiita.com/ms_os_pssb/items/fa434ed1d61ca8256a99)
に引き続き、カスタムしたredmineのdockerを動かすためにAWS側の設定をしていきます。

大きな流れ(復習)

1.Dockerfileを用意
2.AWSにてElastic Container Service(ECS)のタスクを定義
3.ECSのインスタンスを用意

今回は2を行います。

2.AWSにてElastic Container Service(ECS)のタスクを定義

見出しはタスクの定義としてますが、実際にはこんな作業が必要です。
なお、Redmineで使用するデータベースはRDS(MySQL)を利用しています。
(MySQLの用意方法は割愛)

2.1. Amazon EC2 Container Registryにdockerイメージの格納場所を用意
2.2. ローカルの端末でDockerfileをビルドし、2.1にて作成したRegistoryにpushする。
2.3. ECSのタスク定義にてpushしたイメージをつかうよう設定したタスク定義を作成

2.1 Amazon EC2 Container Registryにdockerイメージの格納場所を用意

  • 管理コンソールより、「EC2 Container Service」→「リポジトリ」→「リポジトリの作成」ボタンをクリック。リポジトリ名を入れ、作成完了

スクリーンショット 2017-05-29 16.20.51.png

スクリーンショット 2017-05-29 16.27.17.png

2.2. ローカルの端末でDockerfileをビルドし、2.1にて作成したRegistoryにpushする。

上記にて完了画面に出てきたコマンドをローカルで実施。Dockerfileのビルドとregistoryへのpushを行う。

#事前にaws configにてローカル端末にawsアカウントを設定していること
aws ecr get-login --region (リージョン名)
# dockerfileおよびdocker-entrypoint.shファイルがあるフォルダ上で実施
docker build -t redmine .
docker tag redmine:latest xxxxxx(awsアカウント+region).amazonaws.com/redmine:latest
docker push xxxxxx(awsアカウント+region).amazonaws.com/redmine:latest

2.3 ECSのタスク定義にてpushしたイメージを使うように設定したタスク定義を作成

-管理コンソールより、「EC2 Container Service」→「タスク定義」→「新しいタスク定義の作成」を選択する。
-「コンテナを追加」より、詳細内容を入力

実際に動作しているものをキャプチャします。

スクリーンショット 2017-05-29 18.36.14.png

ポイント
  • タスク定義名→適当、タスクロール→なしでOK
  • コンテナイメージに先ほどpushしたイメージのパスを貼り付け
  • メモリ→512MBもあれば十分。
  • ポートマッピング→3000portで動作するイメージのため、ホスト側の80とマッピング
  • マウントポイント→configの内容(database.yml)を置く場所と、添付ファイルを置くフォルダをホスト側のディレクトリにマッピングするために設定する。ボリュームにてホスト側のディレクトリのソースパスを指定したものを用意し、マッピングにて設定する。
  • ログ設定でcloudwatchのロググループを指定している。例ではあらかじめ「redmine-log」というロググループを作成し、それを指定している。

ようやくDockerのイメージの動作定義まで出来たので最後にイメージを動かすインスタンス(EC2)の用意をします。

(次回/最終回に続く)

続きを読む