EC2のインスタンスタイプを変えて経費削減

はじめに

EC2の料金が高かったので、EC2のインスタンスタイプを変えることによって、安くした体験談です。
実際に対応したのは2017年8月で、awsでは、頻繁に値段が変わるので注意してください。

元の環境のインスタンスタイプ

m3.medium(200台ぐらい)

変更後の環境のインスタンスタイプ

m4.large(100台ぐらい)

スペック比較

タイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Linux/UNIX 料金
m3.medium 1 3 3.75 1 x 4 SSD $0.096 /1 時間
m4.large 2 6.5 8 EBS のみ $0.129 /1 時間

スペックは倍以上にもかかわらず価格は1.3倍!!

結果(1時間あたりの単純計算)

元の料金
$0.096×200=$19.2

変更後の料金
$0.129×100=$12.9

結果
約33%削減

注意点

インスタンスのスペックを倍にしたところでCPUを使いきれないアプリケーションだと、意味がないので気を付けてください。
(アプリケーションの設計やautoscaleのルール等を見直た方が良いです)
今回実施したアプリケーションではマルチプロセスで動いておりCPUも使い切っていたので上手く行きました。
インスタンスタイプを変えることによって思わぬことが起きたりもするので、十分テストしてから移行して下さい。

最後に

検証は必要だったとはいえ、インスタンスタイプを変えるだけで、経費削減できたのは大きかったです。
台数が減ったことにより運用負荷や他のサービスへの負荷も減っていて経費削減以外のメリットもありました。

続きを読む

AWS EC2のCentOSをPVからHVMへ移行する

(2年前の下書きを発見したので、時期を外していると思いつつ投稿します)
この記事では、昔から使われていたParaVirtualのEC2インスタンスをHVM対応とし、旧タイプのインスタンスから脱出するための手法を記します。
特に t1.micro で CPU steal に悩んでいる方は早めに t2.micro への移行をおすすめします。CPUクレジットに注意する必要がありますが、早い(CPU/network/storage)安い/うまい(メモリ1GB)と使わない理由がありません。
何度か作業をし、出来るだけ手順化をしてみたのでみなさんと共有します。
可能な限りコマンドライン一撃で終了できるようにしています。

先人の知恵

http://qiita.com/cs_sonar/items/21dbb3462708e146a426
実際の作業手順は上記のエントリーそのままですが、出来るだけsedなどのコマンドを利用しコピペで片付くような手順になっています。

作業用インスタンスを準備する

t2.micro/Amazon Linux(CentOSなどでも問題ないでしょう)でEC2を起動します。
このインスタンスIDが i-IIIIIIII として進めます。

EBSを準備する

作業用のインスタンスにアタッチするためのEBSが必要になります。
必要なEBSは二種類です。

出力先となるEBSを準備する

以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
移行元のEBSのサイズより大きなものにしましょう。(でないと収まらない)

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000

ここで作成されたEBSボリュームIDを vol-DDDDDDDD として次に進みます。

出力先EBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdo --volume-id vol-DDDDDDDD

元となるEBSを準備する

元となるEBSですが、以下の順序で作成します。
以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
– 移行元のEBSからスナップショットを作成します。
– 作成したスナップショットから作業用EBSを作成します。

aws ec2 create-snapshot --volume-id vol-OOOOOOOO

ここで作成されたスナップショットのIDを snap-OOOOOOOO として次に進みます。

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000 --snapshot-id snap-OOOOOOOO

作成されたEBSボリュームIDを vol-SSSSSSSS として次に進みます

元となるEBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdm --volume-id vol-SSSSSSSS

作業用インスタンスでの作業

作業用インスタンスには以下の状態でEBSがマウントされている(はず)です。

デバイス名 利用用途
/dev/xvdm 移行元EBS
/dev/xvdo 移行先EBS

移行先データ用EBSを準備する

yum -y install parted resize2fs
parted /dev/xvdo --script 'mklabel msdos mkpart primary 1M -1s print quit'
partprobe /dev/xvdo
udevadm settle

移行元データの検査とディスクサイズの(見かけ上の)縮小

e2fsck -f /dev/xvdm
resize2fs -M /dev/xvdm

移行元EBSから移行先EBSへのデータ移設と縮小したディスクサイズの復元

dd if=/dev/xvdm of=/dev/xvdo1 bs=4K count=1747941
resize2fs /dev/xvdo1

移行先EBSのマウントとchrootによる作業準備

mount /dev/xvdo1 /mnt
cp -a /dev/xvdo /dev/xvdo1 /mnt/dev/
chroot /mnt

grub導入と設定の調整

yum install -y grub
ln -s /boot/grub/menu.lst /boot/grub/grub.conf
ln -s /boot/grub/grub.conf /etc/grub.conf
rm -f /boot/grub/*stage*
cp /usr/*/grub/*/*stage* /boot/grub/
rm -f /boot/grub/device.map
cat <<EOF | grub --batch
device (hd0) /dev/xvdo
root (hd0,0)
setup (hd0)
EOF

menu.lstの調整

menu.lstでの root kernel を調整します。
– (hd0)ではなく(hd0,0)とする必要があります。
– デバイス名ではなくラベル名でrootを認識させます。
– シリアルコンソールとHVM対応を明示します。

sed -i.bak -e 's:root(.*)(hd0):root1(hd0,0):;s:root=.*:root=LABEL=/ console=ttyS0 xen_pv_hvm=enable:' /boot/grub/menu.lst 

以下のような形になっているか確認して下さい。 root kernel あたりが要確認項目です。

default=0
timeout=0
hiddenmenu
title SUZ-LAB CentOS 6
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.1.2.0.1.el6.x86_64 ro root=LABEL=/ console=ttyS0 xen_pv_hvm=enable
initrd /boot/initramfs-2.6.32-431.1.2.0.1.el6.x86_64.img

fstabの調整

fstabでのroot(/)をラベルで認識するように変更します。

sed -i.bak -e 's:.*(s)/s(.*)defaults(.*):LABEL=/1/2defaults,noatime3:g' /etc/fstab 

以下のような形になっているか確認して下さい。 LABEL=/ / あたりが要確認項目です。

LABEL=/ /        ext4    defaults,noatime        1 1
none             /proc     proc    defaults        0 0
none             /sys      sysfs   defaults        0 0
none             /dev/pts  devpts  gid=5,mode=620  0 0
none             /dev/shm  tmpfs   defaults        0 0
/mnt/swap/0.img  swap      swap    defaults        0 0

ディスクラベルの調整

e2label /dev/xvdo1 /
tune2fs -l /dev/xvdo1 |grep name

chrootを退出して後片付け

chroot状態から元のOSへ戻ります。

exit

一時的に必要とされたデバイス関連ファイルを削除し、マウントを解除します。

rm -f /mnt/dev/xvdo /mnt/dev/xvdo1
sync
umount /mnt

AMIの作成

AMI作成のもととなるスナップショットを作成する

aws ec2 create-snapshot --volume-id vol-b7f1e741

作成したスナップショットからAMIを作成する

続きを読む

AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選

【 はじめに 】 ※現在絶賛執筆中!

~ 現段階 (2017/09/25) では、AWSサービスのことをほとんど知らない ~

今回、AWS初心者の僕がインフラ設計/構築の担当者になった。何事も経験だ!」と、自分から手を挙げたものの、
覚えることが多すぎやしないか?と思いつつ、これも自分の伸びしろだと、、まだまだ伸びる証拠だと
ポジティブに捉えて(本田風)
、絶賛AWSサービスと格闘する毎日を送っている自称ITエンジニアの奮闘記である。

【 現状の課題とその解決策 】

作業を開始してから2週間程度が経過した時点で、このまま場当たり的に知識を身に着けて行くのは、
かなり効率が悪いということに気が付いた。( 自分で言うのも何だが遅すぎないか? :man_tone5: )

もちろん現場で起こっている課題を解決しながら、
場当たり的に問題解決能力を知識を身に着けていくことも重要だと思う。

しかしながら、この局面 (AWSのサービスを全く知らない。インフラに関しての知識はゼロ。) においては、
クラウドの基礎知識を体系的に一からきちんと知識を身に着けていく戦法が有効
だと考える。

理由は、下記の通り。


  • 各単語の関係性についても合わせて学習することにより、単語の忘却曲線をより緩やかにすることができる。
    現状の課題 (1) : 単発だと結構すぐに忘れてしまう。
  • クラウドの全体像を把握するスピードが早くなるので、効率よく知識を吸収することができる。
    現状の課題 (2) : 基礎知識を短期間で習得できるので、後々応用が効きやすい。
  • いきなりAWSコンソール画面を触って間違えてしまうといったような無駄が無くなる。
    現状の課題 (3) : 基礎がないので、想定していないミスをするケースも。。(痛い目に合うのも大事だけどw)

上記のような理由より、自分の知識を蓄積し、常にアップデートしていくため手段 (備忘録) として、
Qiitaに思考プロセス等を書き残していこうと思う。

(他の人がこれを読むことで勉強になるかどうかは分からないですが、、。)

【 対象読者のみなさん 】

  • 業務でインフラを担当することになったけど、どうしたら良いのかイマイチ分からない人
  • インフラ構成図を見て一通り内容を理解しておきたい人
  • AWSインフラに興味があるけど、触ったことがない人

etc ..

【 お願い 】

もし、本記事の内容に「誤り・誤字」があれば、遠慮なくお気軽にご指摘いただければ幸いです。

それでは、AWSでのインフラ構築担当になってまず最初に覚えたワード15選について、
筆者が参考にしたサイト、各概念の分かりやすい表現をPickUp:point_up:!しながら、
ご説明させていただこうと思います。

読んでいただいた方のお役に立てるような記事にしたいと思っていますので、
どうぞ最後までお付き合いください
:grinning: !!!

【 本編 】AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選

まずは、「AWSって何なの?」ってところから。
  
amazon-web-services-logo-large1-e1334297880876.png

00. AWSの基本概念

AWSは、「Amazon Web Service」の略なんだけど、AWSとは?
と何も見ずに語れるほどの知識はないので、この部分に関しては後日アップデートする予定です。

[ 2017/10/13(Fri)時点での、筆者のAWSへ対する認識 ]

クラウドコンピューティングのリソースを提供していて、その上に様々なサービスを乗っけて、
誰でも簡単に?使った分だけの費用(従量課金)でインフラ環境を構築できるサービスってイメージ。

クラウドコンピューティングのリソースというのは、
世界各地にあるAWSが保有しているデータセンターのことなんだけど、、

まず最初に、

どの地域 [リージョン(Region)] のコンピューティングリソースを使用するのか?

ということを決めないといけない。

1. リージョン (Region)

リージョン(Region) 自体は「範囲、領域」を持つ英単語 :point_up:
Amazon クラウドコンピューティングリソース世界各地の多くの場所でホストされており、
これらの世界各地の拠点、物理的に離れている領域のことリージョン(Region)と言います。

2017/10/12(木)時点で、世界中に16個ものリージョン(Region)が存在します。

(以下、「AWS公式サイト」より引用。)

image.png

※今後、さらに5つのリージョンが追加される予定みたいです。(2017/10/12時点)

・中国
・フランス
・香港
・スウェーデン
・米国 (2番目のAWS GovCloudリージョン)

初めてAWSサービスに触れられる方は、とりあえず何も考えずに、
アジアパシフィック(東京リージョン)を選ばれることをお勧めいたします。

※別途リージョン選択についての細かな部分について紹介する記事を書こうと思います。

[参考サイト]


各リージョン内にはかならず2つ以上のアベイラビリティーゾーン (≒データセンター)と呼ばれる拠点があります。

続いては、そのアベイラビリティーゾーンについてご紹介したいと思います。

2. アベイラビリティーゾーン (AZ : Availability Zone)

アベイラビリティーゾーンを物凄く分かりやすく、簡単に言うと、、。

東京リージョン(物理的に離れた地域)= 東京という都市(場所)に、3つの独立したデータセンター(拠点)が存在し、
この各々のデータセンターのことを「アベイラビリティーゾーン(AZ)」と言います。

AWS.jpg

* 1つのリージョン内に2つ以上のアベイラビリティーゾーン(データセンター)が存在するので、
インフラ設計をする際は、複数のアベイラビリティーゾーン(Multi-AZ)を活用することにより、
構築するインフラ/アプリケーションの耐障害性を向上させることができます。

「リージョンとアベイラビリティゾーンに関する概念について」

各リージョンは完全に独立しています。各アベイラビリティーゾーンも独立していますが、
同じリージョン内のアベイラビリティーゾーン同士は低レイテンシーのリンクで接続されています。

リージョンとアベイラビリティーゾーン」より引用

3. VPC (Virtual Private Cloud)

AWSクラウドの論理的に分離した領域 (セクション) を、誰でも簡単に用意することができます。

下図のようなイメージです。

VPC.jpg

この VPC (Virtual Private Cloud) を活用すると自分で定義した仮想ネットワーク内
AWSリソース (ex. EC2,RDS) を起動させることができます。

VPC (Virtual Private Cloud) のIPアドレスは、以下規則で指定することができます。

  • VPC全体で1つのIPアドレスを持つ
  • サブネットでIPアドレス空間を分割する

[ ※注意 ]
ネットワークアドレスは作成後変更不可なので、あらかじめ20ビット以下など、
ある程度のレンジを持つアドレスを設定しておくのが無難です。

[参考サイト]

4. サブネット(Subnet [Public, Private])

サブネットとは、大きなネットワーク (≒VPC) を
複数の小さなネットワークに分割して管理する際の管理単位となる小さなネットワーク (≒サブネット) のこと。

※下図のようなイメージ。

Subnet.jpg

自分で定義したネットワーク(VPC)を複数のネットワークに分割するために使用します。

具体的には、各インスタンスの役割ごとにグループ化 (サブネットに分割) し、
ルートテーブルをアタッチする際などに使われることが多い (きめ細やかなアクセスコントロールが可能) です。

[ パブリックサブネット ][ プライベートサブネット ] の違いについて


まずは、下図をご覧ください!

Subnet2.jpg

上図の通り、インターネットからVPCインスタンスに接続する ためには、
インターネットゲートウェイ (次項で説明) を用意する必要があります。
そして、VPCネットワーク内にあるルーターを介して、各サブネット内のインスタンスへ通信が行われます。

この時、各サブネットにアタッチされているルートテーブル (経路制御表) の内容に沿って、
インターネットからのアクセスを許可するのか、許可しないのかを判断します。

上記の違いで、パブリックサブネット, プライベートサブネットの区別をしています。

  • インターネット(外部ネットワーク)からのアクセスを許可したサブネットを「パブリックサブネット
  • VPC内部の通信のみ許可しているサブネットを「プライベートサブネット

[参考サイト]

5. インターネットゲートウェイ (Internet Gateway)

インターネットゲートウェイは、VPCのインスタンスとインターネットとの間の通信を可能にする
VPCコンポーネント。

こちらのインターネットゲートウェイの役割大きく2つあります。


1. みなさんが作成したVPCネットワークのルートテーブルに、
インターネットへルーティングが可能な宛先を追加すること。

2. パブリックIPv4アドレスが割り当てられているインスタンスに対して、
ネットワークアドレス変換(NAT)を行うこと。


[参考サイト]

6. デフォルトゲートウェイ (Default Gateway)

所属するLANなどの内部ネットワーク (AWS上のサブネット) から、
外部にあるネットワーク(他のサブネットもしくは、インターネット)に通信を行う場合の
出入り口の役割を果たすよう設定されているルーターやコンピューターのことです。

デフォルトゲートウェイは、
ネットワーク上でプロトコル(規約)が異なる複数のデータを相互に変換し通信を可能
にします。

[参考サイト]

7. ルーター(Router)

IP(Internet Protocol)で通信する端末は、まず最初に通信相手が自分と同じネットワーク(同一サブネット内)に
属する端末かどうかを調べ、自身の属するネットワーク外への通信であれば、ルーター(Router)を経由して
通信を行います。

[参考サイト]

8. ルートテーブル (経路制御表:ルーティングテーブル)

ルーターや端末が保持するパケットの配送先に関する経路情報。

VPCの各サブネットをルートテーブル

ルートテーブルの生成・管理方式には、下記2種類が存在します。


・Static Routing (スタティックルーティング)

経路情報を各ルーター内に手動で設定する手法で、
この経路情報は基本的にルート・テーブルより消えることがありません。

・Dynamic Routing (ダイナミックルーティング)

RIP(Routing Information Protocolo)」「OSPF(Open Shortest Path First)
BGP(Border Gateway Protocol)」などのルーティング・プロトコルを用いて、
ルーターが経路情報を自動的に学習する手法で、この経路情報は動的に更新されます。


[参考サイト]

9. NAT (NAT Gateway)

NATとは、Network Address Translationの略称であり、IPアドレスを変換する技術です。
一般的には、プライベートIPアドレスをグローバルIPアドレスに変換する技術とされています。

ex.
企業LAN内のクライアントPCがインターネットに接続する場合に、プライベートIPアドレスを
グローバルIPアドレスに変換する必要があります。

この時に必要になる仕組みが、NAT(NAT:Network Address Translation)です。

10. 踏み台(Bastion)サーバー

メンテナンスの為の接続経路用途で用意されるサーバーのことを指します。

具体的には、アプリサーバー自体が外部(インターネット)から直接SSH接続を受け付けること自体、セキュリティの観点からもよろしくないので、外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そして、そのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えを取ることでセキュアな環境を実現することができます。この時に用意するサーバーが上記の踏み台(Bastion)サーバーとなります。

また、踏み台サーバーは管理者が使用する時間帯以外は停止状態にしておくことにより、
部外者が勝手に侵入するといった心配もなくなるので、セキュアな構成を実現できる仕組みとなります。

(以下、近日中アップデート予定)

11. セキュリティグループ

異なるセキュリティグループに属するインスタンスと通信を行う際に、
トラフィックの制御を行う仮想ファイアウォールとして機能します。

※セキュリティグループはサブネット単位ではなく、インスタンス単位で設定する必要があります。

また、インスタンスを起動 ( 新規作成 ) する際には、対象のインスタンスと1つ以上のセキュリティグループとの
関連付けが必須となります。

[参考サイト]

12. ElasticIP

13. VPCエンドポイント

[参考サイト]

01. アクセスポリシー

AWSでのアクセスポリシーオプション (アクセス制御 ) は、大きく2つに分類されます。

  • リソースベース(S3のバケットやオブジェクトに対して)のポリシー
  • ユーザーポリシー

どのようなアクセス制御をしたいかによって、
リソース自体に閲覧等の権限を付けるもの (リソースベースのポリシー)
ユーザー単位で操作可能範囲を決めるもの (ユーザーポリシー)など、
柔軟性の高いアクセスポリシー設定が可能です。

本記事では、それぞれ代表的なものを一つずつ紹介したいと思います。

14. IAM (Identity and Access Management) 【 ユーザーポリシー 】

ユーザーに対して、AWSへのアクセスを安全に制御するための仕組み。 AWSコンソール画面から設定が可能で、
IAM (Identity and Access Management) の利用自体が課金対象になることはありません。 (基本無料)

IAMを使用することにより、下記のようなケースでアクセス制御を行うことができます。

  • どのユーザーがAWSリソースを使用できるか?
  • (リソースを使用できる場合)どのような方法で使用することが可能か?

[参考サイト]

15. ACL (Access Control List) 【 リソースベースのポリシー 】

リソースごとに少しずつ設定方法が異なるみたいですが、今回はS3()のバケットやオブジェクト
に対してのアクセス管理について紹介したいと思います。

各リソースには、サブリソースとして、ACLをアタッチする必要があります。
このACLによって、アクセスが許可されるAWSアカウントまたはグループと、アクセスの種類が定義されます。

当該リソースに対するリクエストを受信すると、Amazon S3はアタッチされたACLの内容を調べて、
リクエスト送信者がACLの内容を満たしているか判断します。

[参考サイト]

00. ランク外だけど重要なキーワード

16. シークレットキー

[ 筆者失敗談 ]

[※注意!] するほどでもない話。

もし、AWSのアカウントを取得されている方でこれからEC2インスタンスを生成するという方、
S3に新しいバケットを作られるという方はですね、今一度AWSコンソール画面右上のリージョン設定を
ご確認いただくことをお勧めいたします。

image.png

僕は気が付いたら、米国西部 (オレゴン) のリージョンでEC2インスタンスを立ち上げていて、
他のEC2インスタンス(東京リージョンで作成済み)がコンソール画面で確認できないので凄く焦りましたw

みなさんはこんな凡ミスはしないとは思いますが、一応ここに間違えた人間がいるので、記載しておきます。

最後に

今後記事内容をアップデートしていきながら、自分自身もAWSへの知見を深められたらなと思います。
最後までお読みいただき、ありがとうございました (^^)/

続きを読む

logmonとALBのdrainingでリロード攻撃(F5アタック)へのパッシブ対策

以下の記事で紹介した小ネタの、具体的な利用例です。

1. 対策の内容

リロード攻撃(F5アタック)への対策としては、前段のApacheにmod_dosdetectorやmod_evasiveを入れる、WAFを導入する等があります。
このように、前段ですべて対応できれば良いのですが、

  • リロード攻撃を行っているのが正規ユーザである
  • リクエストによって(また、ユーザ毎に処理に必要なデータ量の多寡によって)レスポンスタイムにばらつきがある

というような場合、なかなか前段だけでの対処は難しいのではないかと思います。
そこで、Webアプリケーションサーバ(Tomcatなど)の処理が詰まってしまったときに、サービスの完全停止を避けるためにWebアプリケーションサーバの再起動を行うことがあると思いますが、

  • 「処理が詰まった」といっても、詰まり始めのうちは「特定の遅い処理」だけが「詰まる」のであり、それ以外のリクエストに対する処理は正常にレスポンスを返すことができている
  • 正常なレスポンスを返すことができるリクエストまで、再起動で中断するのは(なるべく)避けたい

ということで、Apacheのgraceful restartのような処理をしよう…というのが今回の内容です。

※きちんとgracefulな処理をするためには、Webアプリケーションサーバは複数台必要です。

2. ポリシー・IAM Roleの準備

まずは、先ほどの記事にある通り、以下の作業を行います。

  • ポリシーを設定する
  • 設定したポリシーをEC2用IAM Roleにアタッチする
  • そのIAM RoleをEC2(Webアプリケーションサーバ)にアタッチする

なお、今回のケースでは、「ec2:DescribeInstances」に対する権限は不要ですので、この部分はカットしても良いでしょう。

3. EC2上の設定

以下の記事を参考に、EC2(Webアプリケーションサーバ)にlogmonを導入します。

logmon.confには、以下の内容を設定します。

  • 1行目 : 監視対象のログファイル(Apacheのエラーログなら「:/var/log/httpd/error_log」など)
  • 2行目 : 監視対象のキーワード(正規表現/Tomcatのレスポンスが返らない場合を拾うのなら「[error] (70007)The timeout specified has expired」にマッチする内容)
  • 3行目 : 先の記事に示されているとおり

続いて、最初の記事で紹介したスクリプト「aws_utils.sh」を配置し(私の例では「/usr/local/sbin/」内)、「get_instance_id()」の部分だけ以下の内容に置き換えます。

aws_utils.sh(変更部分のみ)
#######################################
# 自身のインスタンス ID を取得する
# Returns:
#   INSTANCE ID
#######################################
get_my_instance_id() {
  instance_id=`/usr/bin/curl http://169.254.169.254/latest/meta-data/instance-id`
  if [ -z "$instance_id" ]; then
    echo 'host not found'
    exit 2
  fi
  echo ${instance_id}
}

※draining(登録解除の遅延)時間の長さに合わせて「SLEEP」の秒数も調整します。

それから、crontabから一定間隔で呼び出すスクリプト(私の例では「/usr/local/sbin/check_count.sh」)を配置します。

check_count.sh
#! /bin/sh

# スクリプトをインポートする
. /usr/local/sbin/aws_utils.sh

# トリガ判定
if [ `cat /tmp/logmon_count` -ge 20 ]; then

  # 閾値越え -> logmonサービス停止
  /sbin/service logmon stop

  # 二重トリガ起動防止(countを0に)
  echo 0 > /tmp/logmon_count

  # ALBでターゲットグループから外す
  ALB_TARGET_GROUP_ARN=('arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXXXX:targetgroup/YYYY/zzzzzzzzzzzzzzzz' 'arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXXXX:targetgroup/YYYY/zzzzzzzzzzzzzzzz')
  INSTANCE_ID=$(get_my_instance_id)

  for arn in ${ALB_TARGET_GROUP_ARN[@]}
  do
    alb_deregister ${arn} ${INSTANCE_ID}
  done

  # ALBでdraining完了待ち
  for arn in ${ALB_TARGET_GROUP_ARN[@]}
  do
    alb_waiter ${arn} ${INSTANCE_ID} 'unused' > /dev/null
  done

  # Webサービス停止
  /sbin/service tomcat8 stop

  /bin/sleep 10

  # サービス起動
  /sbin/service tomcat8 start

  /bin/sleep 10

  /sbin/service logmon start

  # ALBでターゲットグループに戻す
  for arn in ${ALB_TARGET_GROUP_ARN[@]}
  do
    alb_register ${arn} ${INSTANCE_ID}
  done

  # ターゲットグループに戻ったことを確認する
  for arn in ${ALB_TARGET_GROUP_ARN[@]}
  do
    alb_waiter ${arn} ${INSTANCE_ID} 'healthy' > /dev/null
  done

fi

# countを0に
echo 0 > /tmp/logmon_count

if文の「20」は閾値です。適切な値に調整してください。
この例ではWebアプリケーションサーバとしてTomcat8を使っていますが、適切なものに置き換えてください。Tomcatの場合は、draining前後でPrintClassHistogramの出力などもしておくと良いです。

また、この例ではEC2(Webアプリケーションサーバ)を複数のターゲットグループ(配列「ALB_TARGET_GROUP_ARN」)に登録しています。
それぞれのターゲットグループでdraining時間が違う場合は、時間が短いものを先に記述すると良いです(後述の通りログを記録する場合は特に)。
1つの場合は配列にせず、for文で回す必要もありません。

なお、この例ではログを /dev/null に捨てていますが、実際に使うときにはきちんとログファイルに記録しておいたほうが良いです(時刻などとあわせて)。

最後に、このスクリプトを、実行ユーザ(rootなど)のcrontabに登録します(私の例では1分間隔で実行⇒閾値は1分当たりのカウントに対して設定)。このとき、1行目に「SHELL=/bin/bash」を挿入しておきます。

crontab登録例
SHELL=/bin/bash

*/1 * * * * /bin/sh /usr/local/sbin/check_count.sh

設定できたら、カウントファイル(私の例では「/tmp/logmon_count」)に閾値以上の値を書き出して、正しくdraining→ターゲットから削除→Webアプリケーションサーバ再起動→ターゲットに登録が行われるか、確認します。

テスト
echo 20 > /tmp/logmon_count

4. 注意点

drainingすると再起動には時間が掛かるので、Webアプリケーションサーバは最低でも4台程度は必要です。

続きを読む

CodeBuildのbuildspec.ymlを別の名前にしたいときの手順

TL;DR

CodeBuildを使っていると、ビルドの成果物が違うからビルドスペックのファイル(buildspec.ymlというもの)の単位で成果物を分けたいということがあります。調べてみると、ドキュメントに1にやり方が載っていたのでやってみました。方向性としては、AWS CLIで変更操作をする手順です。2

(2017-10-13 22:00 追記。 今さっき見てみたら、Consoleでファイル名を指定できるようになっていました。ちょろっと直すならConsoleでいいですね。)

概要

nantoka-buildというプロジェクトのビルドスペックのファイルをnantoka-kantoka-buildspec.ymlに変えたいとします。windowsの例ですが、mac でも linuxでも概ね同じでしょう。

プロジェクトの名前を確認する

Consoleから確認することもできますが、CLIと同じものが見えているか確認する意味も込めてやってみましょう。

>aws codebuild list-projects
{
    "projects": [
        "nantoka-build",
        "kantoka-build-project",
        "test-test-project"
    ]
}

>

各環境とかリージョンとかで色々あると思いますが、Console 
https://ap-northeast-1.console.aws.amazon.com/codebuild/home?region=ap-northeast-1#/projects
で、見えるプロジェクトとおなじビルドプロジェクトが見えていればOKです。nantoka-build以外のプロジェクトも、存在するなら見えていることでしょう。

プロジェクト名を指定して、プロジェクト構造のJSONファイルを取得する

更新の操作はプロジェクト構造のJSONファイルをアップロードする形になります。アップロードするファイルを作るため、現状のファイルをダウンロードします。

>aws codebuild batch-get-projects --names nantoka-build
{
    "projectsNotFound": [],
    "projects": [
        {
            "name": "nantoka-build",
            "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
            "tags": [],
            "artifacts": {
                "packaging": "NONE",
                "type": "CODEPIPELINE",
                "name": "nantoka-artifact"
            },
            "lastModified": 1512341234.783,
            "timeoutInMinutes": 60,
            "created": 1512341234.68,
            "environment": {
                "computeType": "BUILD_GENERAL1_SMALL",
                "privilegedMode": false,
                "image": "aws/codebuild/java:openjdk-8",
                "type": "LINUX_CONTAINER",
                "environmentVariables": []
            },
            "source": {
                "type": "CODEPIPELINE"
            },
            "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3",
            "arn": "arn:aws:codebuild:ap-northeast-1:1234123412341234:project/nantokanantoka"
        }
    ]
}

>

(arnなどは内容を適当にいじっています。表示される項目はあなたのプロジェクトの内容と同じはずです。)

プロジェクト構造のJSONファイルを

コマンドプロンプトに主力されたJSONをファイルに落として修正を入れます。

  • JSONのルートの"projects"の配下を取り出す。
  • "buildspec": "nantoka-kantoka-buildspec.yml"という1行を入れる。JSONなのでカンマ忘れずに。
  • "lastModified" "created" "arn" は消す。JSONの構造が違うというエラーになるので。無くても多分実害ないと想像する次第。本当は正しい書き方あると思いますが未確認です。
update.buildproject.json
{
    "name": "nantoka-build",
    "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
    "tags": [],
    "artifacts": {
        "packaging": "NONE",
        "type": "CODEPIPELINE",
        "name": "nantoka-artifact"
    },
    "timeoutInMinutes": 60,
    "environment": {
        "computeType": "BUILD_GENERAL1_SMALL",
        "privilegedMode": false,
        "image": "aws/codebuild/java:openjdk-8",
        "type": "LINUX_CONTAINER",
        "environmentVariables": []
    },
    "source": {
        "type": "CODEPIPELINE",
        "buildspec": "nantoka-kantoka-buildspec.yml"
    },
    "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3"
}

修正をアップロード

update.buildproject.jsonをカレントディレクトリに置いて、下記コマンドを実行する。

>aws codebuild update-project --cli-input-json file://update.buildproject.json
{
    "project": {
        "name": "nantoka-build",
        "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
        "tags": [],
        "artifacts": {
            "packaging": "NONE",
            "type": "CODEPIPELINE",
            "name": "nantoka-artifact"
        },
        "timeoutInMinutes": 60,
        "environment": {
            "computeType": "BUILD_GENERAL1_SMALL",
            "privilegedMode": false,
            "image": "aws/codebuild/java:openjdk-8",
            "type": "LINUX_CONTAINER",
            "environmentVariables": []
        },
        "source": {
            "type": "CODEPIPELINE",
            "buildspec": "nantoka-kantoka-buildspec.yml"
        },
        "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3"
    }
}

>

Consoleで確認する。

Consoleからプロジェクトを選択し、プロジェクト詳細 -> ビルド仕様の表示 とクリックして進むと、nantoka-kantoka-buildspec.yml と表示されます。


  1. http://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec-ref-name-storage 今のところ日本語にはなってないようです。 

  2. ぶっちゃけた話、Consoleがすぐにでも対応しそうな気もしますが、今時点での手順を残します。 

続きを読む