#opsworks

お久しぶりです、インフラストラクチャー部の沼沢です。 久しぶりのくせに今回は小ネタです。

OpsWorks で管理している EC2 インスタンスのログを、CloudWatch Logs に転送する場合、以前は自前で Chef Recipe を用意して Execute Recipe をする必要がありました。

ただ、(いつからかは把握できてませんが) 現在は、OpsWorks コンソールや CLI だけで簡単に設定できるようになっています。 今回はこれを試してみた結果の共有と、注意点を書き記しておきます。

前提条件

今回試した環境は以下の通りです。 記載のないものは適当に設定していただければ問題無いと思います。

Stack

Chef version: 11.10

OpsWorks Agent version: 3449 (Jun 5th 2018)

Default IAM instance profile: AWSOpsWorksCloudWatchLogs が付与されているプロファイルを指定

Layer

PHP App Server

Network

Public IP Addresses: Yes

Security(以下のセキュリティグループを指定)

Inbound: ルールなし(全拒否)

Outbound: 制限無し(全許可)

Instance

Amazon Linux 2017.09

執筆時点で、OpsWorks で指定できる Amazon Linux の最新バージョン

今回は2台用意し、起動済みとする

Hostname は numatest01, numatest02 とした

試してみる

AWS OpsWorks スタックでの Amazon CloudWatch Logs の使用

上記の公式ドキュメントに書いてある通りではありますが、これを試してみたいと思います。

たったこれだけです。 この設定をしたあと、数分待つと CloudWatch Logs にログが転送され始めます。

ちゃんと出ていました！ログの中身も見てみましょう。

注意点

これ、とても楽チンでとても便利なんですが、見ての通り、画面からは

CloudWatch Logs を On にするか

Stream command Logs を Yes (出力)にするか

出力したいログファイルのパスを定義

この3つの設定しかできないため、画面からでは本来 CloudWatch Logs でできるはずの細かい設定はできないようです。 CloudWatch Logs エージェントのリファレンス

画面から設定を行っただけの状態の /var/awslogs/etc/awslogs.conf の中身はこんな感じでした。

[general] state_file = /var/awslogs/state/agent-state [numa_cwlogs_test/php-app/opsworks-command-log /var/lib/aws/opsworks/chef/*.log] log_stream_name = numatest01 file = /var/lib/aws/opsworks/chef/*.log log_group_name = numa_cwlogs_test/php-app/opsworks-command-log [numa_cwlogs_test/php-app/var/log/messages /var/log/messages] log_stream_name = numatest01 file = /var/log/messages log_group_name = numa_cwlogs_test/php-app/var/log/messages [numa_cwlogs_test/php-app/var/log/cron /var/log/cron] log_stream_name = numatest01 file = /var/log/cron log_group_name = numa_cwlogs_test/php-app/var/log/cron [numa_cwlogs_test/php-app/var/log/secure /var/log/secure] log_stream_name = numatest01 file = /var/log/secure log_group_name = numa_cwlogs_test/php-app/var/log/secure

これを細かく設定したい場合は、CLI で設定するか、従来通り自前で Chef Recipe を用意して Execute Recipe をする必要があります。

CLI は、aws opsworks update-layer のドキュメントを確認したところ、--cloud-watch-logs-configuration というオプションで細かく指定できるようです。

あとがき

<img alt="Dan Meyer" src="https://res.cloudinary.com/sdxcentral/image/fetch/w_75,h_75,c_lfill,g_auto,f_auto,q_auto,dpr_auto/https://www.sdxcentral.com/wp-content/uploads/2017/04/Dan-Meyer-Senior... SDxCentral Feed

はじめに

はじめまして、メディアシステム開発部の森と申します。 主にauスマートパスの一部サービスの開発周りを担当しています。

皆様はAWS OpsWorksは利用されていますか？

AWS OpsWorks(以後OpsWorksと表記)とは、EC2やELBといったAWSリソースをスタックという単位にまとめて管理や運用ができるソリューションです。

Webサービスの保守、運用に必要な情報（インスタンスの台数や稼働状況 ）が集約されている上、Chefのレシピさえ作ってしまえばアプリのデプロイからミドルウェアアップデートまで、管理コンソールから一通り熟せる優れものです。

詳細は公式をご覧ください。

Time-basedインスタンスって？

OpsWorksには稼働スケジュールを"曜日"と"時間"で指定できるTime-basedインスタンスというものを作る事ができます。

これは、アクセスの多い曜日や時間帯が事前に予測できるサービスであれば、 ピークに備えてインスタンス数を増やしたり、逆に深夜帯は必要最低限のインスタンスのみを動かして他は停止しておく、といった稼働スケジュールを予め設定することが可能となる便利な機能です。

個人的な所感ですが、オートスケールではないので、決められた運用コスト内でやりくりするサービスに向いていると思います。（各インスタンスの負荷状況はOpsWorks上で、まとめてモニタリングできますし）

設定変更も簡単で、コンソール上からポチポチとクリックするだけです。コンソール上の時間の表記はUTCなので注意。

Time-basedのちょっと不便な所

大変便利な機能なのですが、欠点もあります。

設定は1時間単位

コンソール上で設定できるのは1時間単位なので、インスタンス数が多かったり24時間全部に対して設定変更が必要だったりすると、延々とクリックをし続ける必要があります。

10台以上の設定をしないといけない場合は挫けそうになります。

設定は曜日ベース

前述の通り設定できるスケジュールは"曜日ベース"ですので、毎月X日に稼働したいor停止させたいといった設定はできません。せいぜいが対象日に当たる曜日設定を数日前に変更して対応といったことが出来る程度です。(それでも充分かもしれませんが)

欠点を無理やり解消してみる

前置きが長くなりましたが、前述の欠点を解消するべく少し工夫してみます。

設定の一括変更

まずはTime-based設定を曜日単位で一気にやる方法から。

といっても、これは特別な工夫も何も必要なく、AWS CLIにTime-basedの設定変更コマンドが存在しますので、それを使えば設定の一括変更は簡単にできます。公式ドキュメントを元に、一つコマンドを作ってみます。

aws opsworks --region us-east-1 set-time-based-auto-scaling --instance-id インスタンスID(OpsWorks ID) --auto-scaling-schedule '{"Monday": {"0": "on","1": "on"}、,"Friday": {"0": "on","1": "on"}}'

基本的なパラメータは他のCLIと大差なく、このコマンド特有のパラメータは稼働設定の内容を渡すための"--auto-scaling-schedule"くらいでしょうか。

稼働設定は上記例の通りjson形式で設定します。こちらも時間はUTCでの記述となるので、日本の場合は+9時間であることに注意しましょう。

この例の場合、月曜日と金曜日の9時台および10時台だけ対象のインスタンスを稼働させるというスケジュール設定になります。(正確には9:00からインスタンスを立ち上げ始める)

ちなみに

{"Monday": {}、,"Friday": {}}

という設定だと、月曜日と金曜日は稼働しないという設定になります。

擬似的な日付ベースの稼働スケジュール設定

CLIのコマンドを利用し、日付ベースで稼働スケジュール設定をするシェルを大雑把にですが作ってみました。

今回作ったシェルの概要は、

前提として毎日深夜に本シェルを実行する。

対象インスタンスに対し、１日単位で稼働スケジュールを下記条件で設定していく

毎月2日と22日（スマパスの日ですね)は9:00～翌9:00稼働させる。

それ以外の日は稼働停止。

シェル実行日当日とその次の日は設定対象から外す。

といった内容です。 3に関しては設定ファイルのミス等により、いきなり当日の稼働スケジュールが変わってしまった等という事態を避ける為の保険です。

まずは"--auto-scaling-schedule"に入れる稼働スケジュール設定のテンプレートを作ります。 今回の稼働スケジュールパターンは2つのみです。

フル稼働設定のテンプレート(time_based_full.json)

{"%Target%":{ "0": "on", "1": "on", "2": "on", "3": "on", "4": "on", "5": "on", "6": "on", "7": "on", "8": "on", "9": "on", "10": "on", "11": "on", "12": "on", "13": "on", "14": "on", "15": "on", "16": "on", "17": "on", "18": "on", "19": "on", "20": "on", "21": "on", "22": "on", "23": "on" }}

稼働停止設定のテンプレート(time_based_off.json)

{"%Target%":{}}

%Target%は、設定対象日の曜日に置換する文字列です。

次に、どの日にどの稼働スケジュールを設定するかのカレンダーみたいなものを作ります。

稼働設定カレンダー(time_based_calendar.json)

{"Schedule": { "full": [ "2", "22" ] } }

最後に設定対象とするインスタンスのリストを作ります。今回はAz-aしか使っていませんが、Az-cも対象とする場合は"AzC"の配列を追加すればOKです。

設定対象のインスタンスリスト(instance.json)

{"Instance":{ "AzA": [ "インスタンスID(OpsWorks ID)その１", "インスタンスID(OpsWorks ID)その２" ] } }

以上4つの設定jsonファイルを使って、日付ベースによる稼働スケジュール設定の本処理作ります。

実行sh(opsworks_timebased_ctl.sh)

1 #!/bin/bash 2 target_date_list=(`cat ./time_based_calendar.json |jq -r '.Schedule.full[]|@text'`) 3 4 for i in {2..6}; do 5 # スケジュールを操作する対象日を取得します。 6 # [0]・・・日、[1]・・・曜日 7 target_day=(`LANG=en_US.UTF-8 date -v+${i}d "+%d %A"`) 8 9 if `echo ${target_date_list[@]} | grep -q "${target_day[0]}"` ; then 10 schedule_type="full" 11 else 12 schedule_type="off" 13 fi 14 15 target_schedule=`cat ./time_based_${schedule_type}.json |sed -e "s/%Target%/${target_day[1]}/"` 16 17 for instance in `cat ./instance.json |jq -r '.Instances.AzA[]|@text'` 18 do aws opsworks --region us-east-1 set-time-based-auto-scaling --instance-id ${instance} --auto-scaling-schedule "${target_schedule}" 19 done 20 done

・２行目

稼働設定カレンダーから、フル稼働(full設定)させる日を取得し、target_date_list配列に入れます。

・4行目以降のfor分

実行日の明後日〜6日後までの日付を処理します。 6日後までなのは、元々が曜日ベースでの設定だからですね。

・7行目

設定対象である実行日のi日後の日付（日のみ）と、その曜日を取得してtarget_day配列に入れます。

・9行目～13行目のif文

設定対象日の稼働スケジュールパターンを設定します。 今回の場合、フル稼働設定の対象日配列target_date_listに設定対象日が存在した場合は、time_based_full.jsonの内容で稼働スケジュールを設定します。 それ以外は停止させるので、time_based_off.jsonの内容を設定します。

･15行目

設定テンプレートの%Target%を7行目で取得した設定対象日の曜日文字列に差し替えて、target_scheduleに入れます。

・17行目〜19行目

CLIでTime-basedの設定を、インスタンスの台数分for実行しています。

実行環境等により多少の手直しは必要かもしれませんが、動かすだけであれば上記のファイル一式を同じディレクトリ内に配置すればOKです。

毎日深夜0時など日次でシェルを動かせば、毎月2日と22日に関しては、常にその6日前には対象インスタンスのフル稼働設定が完了しています。

完璧にはまだ遠い

結構大雑把なんで、真に日付ベースの設定に対応させるには、ぱっと思い浮かぶだけでも

月末だけ動かしたいというパターンには対応できていない。

時間が9:00～翌日9:00というUTCベースでの設定となっている。

0:00～翌日0:00といった24時間設定をきちんとやるには、設定対象日と合わせて、その前日の稼働スケジュールも一緒に変更する必要あり。

正直このレベルなら、cronで対象日の早朝にでもインスタンスを立ち上げるCLIを発行するシェルを実行したほうが楽じゃないのか？

といった点を解決する必要があります・・・。

まとめ

拙いコードで大変恐縮ではありますが、OpsWorks上で日付ベースのインスタンス稼働スケジュールを設定したい時に、参考として少しでもお役に立てれば幸いです。

まぁ、OpsWorksに日付ベースで稼働設定ができる機能を実装してもらうのがBestなのですが・・・。

Learning AWS OpsWorks

Rating: List Price: Discount: 0.00 Sale Price: (as of 12/31/1969 16:00 PST)Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply to the purchase of this product.. Check Price Right Now! Availability: Free Shipping: unspecified

Product Description

Details

No features available.

New Post has been published on http://cloudifica.com/learning-aws-opsworks-2/

Привіт! Зараз розповім як просто і швидко побудувати інфраструктуру для Symfony2 аппу, яка може автоматично масштабуватися, залежно від навантаження.

Для того щоб запустити Symfony2-проект на платформі AWS потрібно пройти кілька етапів.

Спочатку треба визначитися в якому регіоні буде жити апп. В ідеалі, апп має знаходитися найближче до основної маси цільової аудиторії. Цей регіон і треба вказувати де тільки можна. В даному прикладі будемо використовувати us-west-1 (N. California).

В OpsWorks створюємо новий Stack.

В процесі заповнення форми потрібно створити “IAM role” та “Default IAM instance profile”.

Default SSH key - це SSH-ключ який буде додаватися новим інстансам при створенні. Варто зберегти його в надійне місце, адже в подальшому він не буде доступний для скачування.

В розділі Advanced треба обрати “Use custom Chef cookbooks - Yes”.

Chef cookbook - це набір скриптів для встановлення та настройки серверу та аппу. Потрібно надати доступ до репозиторію з рецептами. Робочий варіант рецептів є тут: https://github.com/ekreative/symfony-chef

Порядок виконання рецептів вкажемо пізніше.

В розділі Custom JSON вказуємо конфігурацію для рецептів (для кожного Layer). Наприклад рецепт “symfony::parameters” згенерує файл app/config/parameters.yml на основі цієї конфігурації. Тобто всі параметри зовнішніх сервісів (mysql, smtp, redis) вказуються тут.

Після успішного створення Stack потрібно додати Layer.

Layer type: PHP App Server

Тепер створюємо App. В “Document root” записуємо значення - web.

Найважливіший розділ цієї форми “Application Source”. Тут додаємо джерело сирців. В прикладі використовуємо git-репозиторій. Крім параметрів доступу дуже рекомендую в поле “Branch/Revision” записувати тег комміту. Це критично в тій ситуації, коли система починає створювати нові інстанси, і якщо нічого не вписати в це поле, то буде використаний останній комміт з гілки master, в той час як існуючі інстанси використовуватимуть старішу версію.

Для репозиторію з рецептами це також актуально.

Тепер, коли система знає джерело сирців, потрібно вказати сценарії створення системи. Для цього потрібно В створеному Layer зайти в розділ Recipes. Далі просто додаємо потрібний рецепт у потрібний розділ.

Типова конфігурація може виглядати так:

Тут встановлюється apache2, конфігурується PHP, міняються права файлів, встановлюється Composer, налаштовується сховище логі (логи будуть доступні в сервісі Cloud Watch), встановлюється npm, bower, gulp. Скидається кеш. Загалом виконуються всі ті команди, які ми виконуємо вручну і які забирають в нас так багато часу.

Базу данних потрібно створити окремо в сервісі RDS. Тут можна створити як окремий інстанс так і реплікацію.

Якщо буде використовуватися більше одного інстанса обов’язково потрібно налаштувати зовнішнє сховище для сесій. Для цього чудово підходить Redis або Memcached. Створити таке сховище можна в сервісі ElastiCache.

Після того як все сконфігуровано й запущено, в розділі Instances треба додати необхідну кількість інстансів. В залежності від потреб можна додавати інстанси різних типів: 24/7 - працюють постійно, і їх пожна запускати і зупиняти вручну. Load-based - запускаються якщо середнє навантаження системи перевищує вказане значення. Зупиняються вони якщо навантаження системи впаде нижче значення зупинки. Time-based - працюють в чітко визначеному інтервалі часу.

При додаванні інстансу виконуються вказані рецепти і після запуску ми маємо готовий до роботи сервер.

Щоб розподілити навантаження між інстансами потрібно додати elastic-load-balancer на кожен Layer.

Домен має посилатися на DNS Name створеного Load Balancer.

Після внесення змін в код системи, потрібно внести зміни в репозиторій, і присвоїти цим змінам тег. Далі потрібно замінити старий тег на новий в розділі App. Після цього в розділі Deployments запустити розгортання системи.

Learning AWS OpsWorks

Rating: List Price: Discount: 0.00 Sale Price: (as of 12/31/1969 16:00 PST)Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply to the purchase of this product.. Check Price Right Now! Availability: Free Shipping: unspecified

Product Description

Details

No features available.

New Post has been published on http://cloudifica.com/learning-aws-opsworks/

重いクエリを検知する仕組みがほしくて、お勉強がてらMpLogと言うものを作りました。

全体の流れは以下のようになります。

cookbookをOpsWorks経由でEC2にrecipeを実行する。

1分毎にshow full processlist が実行されるので、結果をJSON形式でログを出力する。

出力されたログはfluentdでS3とLogglyにPUTされる。

S3にPUTされたものはLambdaでイベント通知されチェックを行なう。

しきい値を超えたログがある場合、LambdaからSlackにPush通知を行なう。

Slackへの通知はこんな感じです(ちょっと見ずらいですが。。。)

ログ解析ツールに関しては Loggly か papertrailで迷ったのですが、Logglyのほうがfluentdのプラグインが存在し、導入と検索が楽なのでこちらを採用しました。

GitHubにもあげていますので興味があればご覧ください。