#jawsdays #jd2017_a
AMI Maintenance
Environment
2017/3/11
JAWS-UG ARCH 神 希嘉
#jawsdays #jd2017_a
{
“name”:“神 希嘉",
"favorite aws service":[
"AWS Route53",
"AWS S3",
"AWS CodeDeploy"
],
"certifications":[
 "AWS Certified Solutions Architect-Associate”,
"AWS Certified Solutions Architect-Professional”,
"AWS Certified SysOps-Admin-Associate”,
"AWS Certified Developer-Associate”,
"AWS Certified DevOps Engineer-Professional”
],
"JAWSUG":[
"CLI専⾨⽀部",
"アーキテクチャ専⾨⽀部",
    "情シス⽀部",
"コンテナ⽀部"
],
“motto”:"ある問題の解決策が⾒当たらなく⾏き詰まったときはその問題を拡⼤させなさい"
}
#jawsdays #jd2017_a
今⽇のお話の全体構成図
Office
Direct Connect
VPN
connection
Cloud Front Route 53
RDS DB
instance
RDS DB
instance standby
(multi-AZ)
AWS Directory
Service
Amazon API
Gateway
Amazon
Cognito
AWS
Lambda
Amazon
DynamoDB
Amazon
S3
AMI
Auto Scaling
EC2
Amazon
Provided
DNS
EC2
Staging
server
Prod
server
Prod
server
Bastion
server
corporate data center
EC2
Elastic Load Balancing
EC2
DNS Server
#jawsdays #jd2017_a
突然ですが皆さん、AMIを知っていますか?
#jawsdays #jd2017_a
AMI(Amazonマシンイメージ)とは
EC2(仮想サーバ)の元となるテンプレートで
要はEC2のイメージとなります。
既に稼働中のEC2のAMIを作成することも可能で
作成することでEC2のバックアップ・リカバリが容易になります。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AMIs.html
#jawsdays #jd2017_a
ここからは
AMIを知っていることを前提のお話となります
#jawsdays #jd2017_a
1. 起動後のEC2のAMIを作成してますか?
2. AMI作成後に起動中のEC2を構成変更してませんか?
3. 構成変更後のEC2のAMIを都度作成してますか?
4. AMIを作成しなくてもCloudFormation とか Docker とか
ChefとかAnsibleなどで構成管理できるようにしていますか?
#jawsdays #jd2017_a
恐らくAMI作成後に⼀切EC2にログインせず、なおかつ
定期的にAMIを取得していている組織はそんな多くないかと
(勝⼿に)思っています。
また、構成管理系のツール導⼊は組織や環境や⽴場・役割に
よってはハードルがあって導⼊しづらいというところも
あるところもあるかと思います。
#jawsdays #jd2017_a
サーバはいつかおかしくなる。
おかしくなったら前の状態に戻さないといけない。
とはいえ構築や設定変更の際にEC2にSSHログインして
構成を変更していると構成管理がしづらくなる。
現在の構成がわからなくなるとEC2に障害が発⽣した際、
同⼀構成のEC2が起動できずにサービスに影響がでてしまう。
#jawsdays #jd2017_a
そうならないためには
#jawsdays #jd2017_a
EC2にSSHログインしないでEC2を構築をすればいい。
EC2を新規に起動するときもSSHログインしないで
構築済みのEC2の構成をそのまま利⽤すればいい。
構成管理系のツール導⼊が難しいのであれば
活⽤しやすいAWSのサービスで構成管理すればいい。
#jawsdays #jd2017_a
ということで今回紹介するデザインパターンは
#jawsdays #jd2017_a
S3でEC2の構成管理をしつつAMI作成環境を構築する
AMI Maintenance Environment
(AMIメンテナンス環境構築)
となります。
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
log
(構築ログ格納⽤)
AMI作成⽤
EC2
*.conf
*.yml等
*.conf
*.yml等
*.log
構築済AMI
user-data.bash
#jawsdays #jd2017_a
今回のアーキテクチャーを(CLIで)試したい⽅はコチラ
【JAWSUG CLI専⾨⽀部 #77】
新CDP ʻAMI Maintenance Environmentʼ
http://qiita.com/tcsh/items/b55eee599ae2c8806e4f#77-%E6%96%B0cdp-ami-maintenance-environment
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
log
(構築ログ格納⽤)
AMI作成⽤
EC2
*.conf
*.yml等
*.conf
*.yml等
*.log
構築済AMI
user-data.bash
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
*.conf
*.yml等
(1) 設定ファイルをS3に格納
log
(構築ログ格納⽤)
S3バケットは事前に作成作業PCでも可
(1) 設定ファイルをS3に格納
user-data.bash
ミドルウェア導⼊等に
必要な設定ファイルを
s3にコピー
EC2構築時にuser-data
で実⾏したいコマンドを
user-data.bashに記述
#jawsdays #jd2017_a
user-dataとは
EC2を起動する際に実⾏することができるスクリプト。
EC2起動時のオプションで記述・指定が可能。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
#!/bin/sh
yum –y intall httpd
service httpd start
chkconfig httpd on
EC2起動
EC2起動時に
こんな感じの
スクリプトを
user-dataに記述
user-dataに記述した
スクリプト実⾏済み
のEC2が起動
EC2 EC2を起動する
⼈
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
log
(構築ログ格納⽤)
AMI構築⽤
EC2
*.conf
*.yml等
*.log
(2) EC2を起動
(4) EC2構築時のログをS3に格納
aws ec2 run-instances
にてメンテナンス専⽤EC2に
保存したuser-data.bashを
user-dataに指定
user-dataの中で
aws s3 sync を実⾏
user-dataの中で
aws s3 cp を実⾏
実⾏結果のログはs3に格納
したログファイルで確認
(3) EC2構築時にconf/yml等を取
得
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
log
(構築ログ格納⽤)
AMI作成⽤
EC2
(5) EC2のAMI作成
(6) EC2をTerminate
構築済AMI
aws ec2 create-image
でAMI作成
aws ec2 terminate-instances
でEC2削除
#jawsdays #jd2017_a
conf
(設定ファイル格納)
メンテナンス
専⽤EC2
log
(構築ログ格納⽤)
AMI作成⽤
EC2
*.conf
*.yml等
*.conf
*.yml等
*.log
(1) 設定ファイルをS3に格納
(2) EC2を構築
(4) EC2構築時のログをS3に格納
(5) EC2のAMI作成
(6) EC2をTerminate
構築済AMI
user-data.bash
(1) 設定ファイルをS3に格納
(3) EC2構築時にconf/yml等を取
得
#jawsdays #jd2017_a
conf
(設定ファイル格納)
log
(構築ログ格納⽤)
構築済AMI
EC2にSSHログインする事なく構築したEC2のAMI作成
スクリプト・設定ファイル・構築ログはs3のバケットで管理
#jawsdays #jd2017_a
RDS DB
instance
RDS DB
instance standby
(multi-AZ)
Staging
server
Staring
server
構築済AMI
RDS DB
instance
RDS DB
instance standby
(multi-AZ)
Prod
server
Prod
server
ステージング環境で
構築済AMIを元にEC2を起動して
動作確認
本番環境で
構築済AMIを元にEC2を起動して
動作確認
Elastic Load Balancing
EC2 EC2 EC2
Elastic Load Balancing
EC2
常にメンテナンスされたAMIでEC2を安全にサービスリリース!
#jawsdays #jd2017_a
サーバはいつかおかしくなる。
おかしくなったら前の状態にいつでも戻せる。
構築や設定変更の際にEC2にSSHログインして操作せず
S3の構成管理できているのでわからなくなることはない。
EC2に障害が発⽣して構築済AMIより同⼀構成のEC2が
起動できるので復旧後のサービスに影響がでてしまうと
いうことがない。
#jawsdays #jd2017_a
となれるよう皆様の参考になれば幸いです
#jawsdays #jd2017_a
今回のアーキテクチャーを(CLIで)試したい⽅はコチラ
【JAWSUG CLI専⾨⽀部 #77】
新CDP ʻAMI Maintenance Environmentʼ
http://qiita.com/tcsh/items/b55eee599ae2c8806e4f#77-%E6%96%B0cdp-ami-maintenance-environment

JAWSDAYS2017 新訳 とあるアーキテクトのクラウドデザインパターン目録 AMI Maintenance Environment