JAWS-UG初心者支部#3を運営してみた
コアメンバーとして運営を実施しました。
イベントの概要はこちら。
twitterでの反応はこちら。
資料や内容については初心者支部公式ブログや参加者の方のブログで書いて頂けると思います。 ここでは私が運営として何をやったか、どんなことを考えたかなど、雑に書いていきます。
全般的に心がけたこと
運営、無理しない
運営自身が疲弊したら続けられないので、省エネ運営を心がけました。
具体的には以下のことをやめました。
- 会場での懇親会、懇親会会場の事前予約
ドタキャンとかで予定より参加人数が減ると運営や参加してくれた方たちの負担が増えるので、やめました。 （そもそも会場的にビアバッシュはNGってのもありましたし）
今回は、当日出欠確認・当日予約で対応できました。 今思うと、金曜なのによく予約できたなと思いますｗ
- 遅刻者への対応
会場が20時以降入場できなくなるのですが、いちいちピックアップすると運営が発表を聞けないので、これもやめました。 運営だっけ発表聞きたいんですよ！（運営やっているからってAWSのこと何でも知ってるわけではないんですよ！）
- 余分なメンバーのアサイン
余分と書くと語弊があるかもしれませんが、あまり多くの方を運営の支援としてアサインすると 事前のタスクの割り振りや当日の指示などのタスクが増えてコアメンバー的には大変なので、 必要最小限の人数で運営しました。
今回は、コアメンバー4名＋facebookで募集した2名＋会場を提供していただいたD2Cさんで対応しました。
2日前の急な募集に対応して頂いた吉田さん、木村さん、D2Cの皆様、ありがとうございました！
テーマの決定
きっかけは↓のイベントに参加した時、運営メンバーの多田さんや山崎さんと、「セキュリティをテーマにしたい！」くらいのノリで決めた気がします。 （ちゃんと覚えてない） 自分が聞きたいテーマを設定できるのは運営最大のメリットですねｗ
会場の確保
第2回目でD2Cの金澤さんに会場提供の申し出を頂いていたのを覚えていたので、まず最初に打診しました。 快く快諾頂き、即決しました。 金澤さん、本当にありがとうございました！！！ D2CさんまじD2C！
登壇者のアサイン
会場を提供いただいたD2C金澤さん、運営メンバーと面識のある方に打診してすぐに快諾をいただけました。 金澤さんにお願いした以外は私はほとんど関わってないと思います。 （あのブログの人とかどう？くらいは言ったかも。） 他の運営メンバーの顔の広さとJAWS-UGのすごさを実感。
登壇内容については、結果的に事例と実践的な内容でバランスがとれた気がしますが、 cloudpackの齋藤さんが他の方の登壇内容を踏まえて内容を考えてくれたと聞いています。 「テーマはセキュリティで！」という割と雑な振りにもかかわらず、なんと素晴らしい配慮！できる男は違いますね～。
ちなみに、アンケートの回答状況を見ると片山さんの評価がぶっちぎりで良いことから、実践的な内容を求めて参加された方が多かったのだと思います。 （実際、エンジニアの方が半分以上でした。） しかし、AWSはあくまで手段であり、目的に合わせてどのように使うのか（使ったのか）も併せて把握・理解することが重要と思っており、個人的にはこのバランスの構成で続けたいなーと思っています。
エンジニアの方は組織の説得とか自分の仕事じゃねーと思うかもしれません。 しかし、意思決定をするひとは必ずしも技術に明るいわけではありません。当然と言えば当然です。 そんなときに、ちゃんと説明できるエンジニアにみんなでなろうぜと個人的には思います。（自分がそうなりたい）
当日のオペレーション
アンケートでもご指摘を頂いていたのですが、受付はもう少し改善する余地がありました。 今回、懇親会の出欠確認もあったので紙で確認をしていましたが、 名前の表記が漢字とアルファベット混在なので確認に時間がかかりました。 受付アプリがあるのは知ってるんですが、懇親会の出欠確認もあるのでとりあえず今回は紙でチェックしました。
次回は、
本編の受付はアプリとブラウザの管理画面を併用
懇親会は本編の受付開始からDoorkeeperで受付開始
といった感じでやるといいかなーと思いました。
また、会場のレイアウト変更および原状復帰も若干課題がありました。
元のレイアウトからの現状復帰を参加者の方に手伝っていただいたのですが、 元のレイアウトがどうだったかをうまく伝えられなかったので、ちょっと時間かかっちゃいました。 早く帰りたかった方、すみません。 最初のレイアウト変更を参加者の方と一緒にやれば良かったなーと反省。 （そうすれば、元に戻しての一言でほぼ済むはず。運営的にも楽できたし。）
司会
一応、司会のようなものをやりました。
初めてなのでどんな感じでやればいいのか全然分からず、 各発表後に質問とかコメントとか言おうと思って聞いてましたが、あまりたいしたことは言えずでした。 本職の人はすごいなー・・・
ちなみに、雰囲気が堅いのは仕様です。ご了承ください。
内輪感問題
個人的には極力注意したつもりでしたが、アンケートにもそれらしい指摘が少しだけありました。 こういう勉強会に慣れているとあまり分からないのでご指摘を頂けることはとてもありがたいと思います。
しかし、限界ありますよね、これだけ長い間やってるユーザグループだと。
この問題を運営が気にしすぎるのも違う気がするので、まずは個人的に気をつけるしかないかなーというのが正直なところです。
ドタキャン問題
今回は71/94と比較的出席率高めでした。 （94はキャンセル処理していただいた方を除いた参加登録数です。） 事前のキャンセル処理をきちんとやっていただいたおかげで、昼頃にはキャンセル待ちが解消されたようでしたので、ドタ参の方も数名参加いただくことができました。 ご協力ありがとうございます。
急な仕事やトラブルでどうしても来ることができないというケースはあると思うので多少は仕方ないと思いますが、 やはりもう少しどうにかならないかなーと思います。 （直前でもいいのでキャンセル処理をお願いします！）
まとめ
今回も、登壇者の皆様、会場を提供いただいたD2Cさん、ノベルティを提供頂いたAWSJさん・cloudpackさん・スカイアーチネットワークスさん、参加者の皆様、お手伝いいただいた吉田さん・木村さん、コアメンバーの青木さん・多田さん・山崎さんのおかげで無事開催できました。 本当にありがとうございました。
個人的にも聞きたかったテーマを設定でき、非常に有意義な発表を聞くことができ、運営やってて良かったなーと思います。
仕事でもっと生かせそうなのでしっかり勉強したいと思って参加するようになった勉強会ですが、 これからも情報を得つつきちんとコントリビュートしていきたいです。
次回のテーマもテンション高い今のうちに決めてしまいたいと思いますｗ
追伸
この文章、自分の性格がにじみ出ている気がする。
EC2インスタンス(Linux)上で簡易的なプロセス監視
Amazon CloudWatchで簡易的なプロセス監視をやってみました。
cronにカスタムメトリックを投稿するワンライナーを登録しただけのものです。
前提条件
設定方法
crontabを編集
crontab -e
カスタムメトリックを投稿するワンライナーを設定（以下のコマンドは、1分ごとにJenkinsを監視した例）
*/1 * * * * aws cloudwatch put-metric-data --region ap-northeast-1 --namespace AWS/EC2 --metric-name process --value `ps aux | grep [/]usr/lib/jenkins/jenkins.war | wc -l` --dimensions Name=InstanceId,Value=`curl http://169.254.169.254/latest/meta-data/instance-id -s`
通知を行う場合は、CloudWatchのアラームやSNSのTopic・Subscriptionを設定してください。
Amazon Cloud Trailを有効化するCloud Formation Template
AWSアカウントを作成する際、プロダクション環境であればCloudTrailを必ず有効にすると思います。
その際、ミスが無いように確認しながらManagement ConsoleやCLIで作業するのは面倒だなーとので、 CloudFormatonのテンプレートを作成しました。 （刺身タンポポ撲滅したい）
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "CloudTrail",
"Resources": {
"S3Bucket": {
"DeletionPolicy" : "Retain",
"Type": "AWS::S3::Bucket",
"Properties": {
"BucketName" : { "Fn::Join" : ["", [ "cloudtrail-", {"Ref":"AWS::AccountId"}, "-", {"Ref":"AWS::Region"} ] ] }
}
},
"BucketPolicy" : {
"Type" : "AWS::S3::BucketPolicy",
"Properties" : {
"Bucket" : {"Ref" : "S3Bucket"},
"PolicyDocument" : {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSCloudTrailAclCheck",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::903692715234:root",
"arn:aws:iam::859597730677:root",
"arn:aws:iam::814480443879:root",
"arn:aws:iam::216624486486:root",
"arn:aws:iam::086441151436:root",
"arn:aws:iam::388731089494:root",
"arn:aws:iam::284668455005:root",
"arn:aws:iam::113285607260:root",
"arn:aws:iam::035351147821:root"
]
},
"Action": "s3:GetBucketAcl",
"Resource": { "Fn::Join" : ["", ["arn:aws:s3:::", {"Ref":"S3Bucket"}]]}
},
{
"Sid": "AWSCloudTrailWrite",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::903692715234:root",
"arn:aws:iam::859597730677:root",
"arn:aws:iam::814480443879:root",
"arn:aws:iam::216624486486:root",
"arn:aws:iam::086441151436:root",
"arn:aws:iam::388731089494:root",
"arn:aws:iam::284668455005:root",
"arn:aws:iam::113285607260:root",
"arn:aws:iam::035351147821:root"
]
},
"Action": "s3:PutObject",
"Resource": { "Fn::Join" : ["", ["arn:aws:s3:::", {"Ref":"S3Bucket"}, "/AWSLogs/", {"Ref":"AWS::AccountId"}, "/*"]]},
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
}
},
"myTrail" : {
"DependsOn" : ["BucketPolicy"],
"Type" : "AWS::CloudTrail::Trail",
"Properties" : {
"IncludeGlobalServiceEvents" : true ,
"S3BucketName" : {"Ref":"S3Bucket"},
"IsLogging" : true
}
}
}
}
S3のバケット名は、「cloudtrail-（AWS ID 12桁）-（リージョン名）」という感じで、AWSアカウントのIDとCloudFormationを実行しているリージョンの名前が自動的に設定されます。
AWSアカウントのIDとリージョンの名前の設定には議事パラメータを、バケット名の連結には組み込み関数を利用しています。
Intrinsic Function Reference - AWS CloudFormation
Pseudo Parameters Reference - AWS CloudFormation
そのため、他のリージョンおよび今後作成するAWSアカウントでも再利用できます。 （バケット名は基本的に一意になると思いますが、保証できるわけではありません。）
Cloud Trailの有効化自体は簡単にできますが、命名規則に則っているか、といった細かい確認が不要になるので心理的には楽かなーと思います。（個人の見解）
JAWS-UG CLI #25 でLTしました
Consolidated Billingの発効日について
AWSでConsolidated Billingを使い始めたタイミングの請求について、ちょっとした注意点があったのでメモ。
Consolidated Billingを使ってアカウントを連結した場合、親アカウントへ請求がされるのは連結した日以降の分のみとなります。 連結した月の料金全てが親アカウントに請求されるわけではありません。 そのため、連結した月の請求は自アカウントと親アカウントにそれぞれ発生します。
詳細は、以下のドキュメントの「発効日」に記載があります。
意識してないとカードの明細に身に覚えの無い請求があるように見えて焦るので注意しましょう。
Instance Profileを設定したEC2インスタンスでAWS Account IDを取得する
タイトルの通りで、これだけです。 （もちろん、これ以外の方法もあります。個人の好みです。）
Metadataに含まれるInstanceProfileのARNから取得しています。
curl http://169.254.169.254/latest/meta-data/iam/info/ | jq .InstanceProfileArn | awk -F':' '{print $5}'
これを書いたのは、JAWS-UG CLI専門支部のハンズオンでAWS Account IDを抽出するコマンドで嵌ったことがきっかけです。
AWS_ID=`aws iam get-user --query 'User.Arn' --output text | sed 's/^.*:://' | sed 's/:.*$//'` && echo ${AWS_ID}
上記のコマンドを実行したとき、ユーザを指定していないとのエラーが出ました。 実行環境はInstance Profileを設定したEC2インスタンス（Amazon Linux）です。
原因を周りに聞いてみたところ、 IAMユーザのCredentialで実行するときに--user-nameを指定していない場合にはコマンドを実行したIAMユーザの情報を出力する仕様になっているとのことでした。 そのため、roleで実行するときには--user-nameは必須のオプションのようです。
公式ドキュメントにも記載がありました。
get-user — AWS CLI 1.7.39 documentation
Options
--user-name (string)
The name of the user to get information about. This parameter is optional. If it is not included, it defaults to the user making the request.
以上、小ネタでした。
ブログ始めました & JAWS-UG 初心者支部 第2回に登壇しました。
JAWS-UG 初心者支部 第2回に登壇してきました。
そのときの懇親会にて、司会の山崎さんにブログ書けとアジテートされたのでブログ始めることにしました。
資料はこちらです。
www.slideshare.net
正直、反省すべき点がいっぱいですが、次の機会にはもう少しうまく伝えたいことを伝えられたらと思います。。。
とりあえず、プレゼンの練習は人に聞いてもらわないとダメだ。。。
内容については、JAWS-UG CLI専門支部で半年くらい前に行ったハンズオンの内容に
- この半年くらいにリリースされた新機能の追加
- なぜその設定を行うのか
といった要素を追加したものになります。
機能や設定があること自体を知らなかったり、その設定をするべきなのか判断できなかったりする方向けの内容なのですが、参考にしていただけるとうれしいです。
設定手順は紹介しておりませんので、自分で手を動かしていろいろ確認してみましょう。
あと、何か足りない点があればぜひ教えてください。
（別に、登壇するからって完璧に知ってるって訳でもないんですよ。特に、AWSは変化が異常に早いので。。。）
勉強会では、AWSの各サービスの機能だったり、AWSを利用して提供しているサービスやその構成に目が行きがちです。（実際、そういうのがおもしろいは間違いない。）
しかし、サービスの継続的な提供や、時間をサービスそのもののために少しでも多く使えるようにするためには、 無用なトラブルを予防したり、トラブルが発生したときに迅速に対応できるようにすることがとても重要だと思います。
当然、お金も大事です。
なので、スルーされがちなこれらの機能についても面倒がらずにしっかり見直してみるといいと思います。
あと、こちらの金庫もよろしくお願いしますｗ
