Secure AWS Users Meetup #1に行ってきた
AWS上でのセキュリティの現場の声が聞ける、Secure AWS Users Meetup #1に参加してきました。 http://connpass.com/event/11019/
セキュリティというところで、現場のシビアな実情が垣間見えて非常に参考になりました。セキュリティを日々どう守るかとかAWS上でどう安全な環境を作るかという視点は今後もっと大切になると感じました。
様々な要望やシステムを守るためにAWSにまだまだ足りない物事や、AWSの勉強会では普段聞けない話が続々とでてかなりハイレベルな勉強会でした！要望などは本当に伝えたいと思います！
キーワードは、認証情報の管理の仕方、しやすさだと感じました。運営の皆様、発表された皆様、ありがとうございました！
次回もあるということで楽しみです！
メインセッション
@kani_b (Cookpad): How to secure your AWS API
- IAMユーザ 250くらい
- AWSではユーザ側とAWS側でセキュリティを守るべき分界点がある
- ユーザ側の世界は主にEC2インスタンスの話
- 基本的な考え方はAWSだからというところが少ない
- もちろん、ミラーポートやIPS/IDSなど出来ない事もある
- AWSは全リソースがAPIで提供されている
- 事故事例
- まずすること
- 権限の分解・最小化 (IAMのこと)
- rootアカウントはリボーク
- MFAの有効化
- IAM User / Role
- 業務フローに合わせて
- MFA / Instance Role
- MFA
- アクセスキーの管理
- bashrcなどに書きがち
- Macならenvchainに入れる
- アクセスキーの管理は課題
- 権限は必要最低限のグループを作って、スタックしてユーザに割り当てていく
- ポリシーの問題点
- ポリシー数が増加すると見通しが悪い
- 変更履歴を管理したい (gitぽくやりたい)
- miamというツール
- GHEで権限のレビュー
- Instance Role
- コードにkeyを埋め込まないように
- instanceに起動時にしか割り当てられない
- OSにアクセスされるとKey取られる！
- CloudTrailやAWS Config
- ログを丁重に扱う
- 改ざんや削除されないように
- S3に配送されるのでMFA Delete
- 監査用ユーザ以外からアクセスされないように
- 別のアカウントに切り出す(監査用のアカウントつくる・バケットポリシーを移譲)
- ログを解析する
- まとめ
- AWSを信頼して任せる気持ちが必要
- ホワイトペーパーなどをよんだり
- やることはやる
- Security on AWS
- アグレッシブに動きやすい
- サーバのアップデートなどが行い易い
@sowawa (WebPay): Slackで作る社内SOC
- PCIDSSv3 レベル1準拠 (on AWS!)
- SOC = Securty Operation Center
- 24/7で監視
- リアルタイム監視が必要なものはIDS/IPSだけではない
- 入室管理
- CI
- デプロイ
- 不正AP
- めちゃくちゃ運用大変/特にスタートアップ
- 開発・運用で24/7の体制をつくる
- そこで、SlackをSOC基盤にする
- Slackはみんなが生活する場だからみんながログを見ることが大事
- DevOps的にセキュリティチェックを行う
- DMZでfluentdで集めてSlackにながず
- PCIDSSの要件として、DMZを通してしかInternetにしか通信しちゃだめ
- 色んなログあるよ
- /var/log/secure (なんか変なことしてるのがわかる/想定外のOPとか)
- Webpayはssh 2FA
- 不正APの検知
- 四半期に1回とか決まってるけどそんなのだめ
- 小さいPCを設置してAPを常に監視
- 入室管理
- 入退室をリアルタイムに監視
- 見える化することはそれだけでセキュリティに大事
- SOC
- O = Operation
- Security meets ops
- セキュリティは運用指定ことが大事
- 組織は常に変わっていくから今は何をしていくべきかを考える
- 自分で出来ないことは他の人に手伝ってもらうのが大事
- 見える化する事による抑止力
野渡さん (CyberAgent): IAM ユーザー管理：awscliを用いたユーザー管理とIDフェデレーションの比較
- プロジェクト毎にAWSアカウントを用意
- 完全な集中管理は行わない
- 開発者を縛りすぎない
- 全てのユーザに一意なIDを割り当てる
- 両極なことを実現しないといけない
- 既存のディレクトリと連携するか
- private cloudやオンプレ環境で培った
- VPC peer
- CloudTrailのログは共通環境のS3バケットに転送
- SAML連携
- MFA無効のユーザにメールを送るなど
- ログインプロファイル外す
- いけてないところ
- CloudTrailで出したログの解析・解析・アラート
- CloudTrail->SNS->SQS->Splunk
- Trusted Adviserを有効活用したい
- Messusの有料の買うと、AWSのセキュリティベストプラクティスのチェックをしてくれる
LT
@xga : セキュアだ！freeeだ！
- secure!
- 200instances
- SG設計
- 2FA必須
- 攻撃検知・脆弱性検査
- SGが増えると管理が大変
- 1 instance 5SGなのが大変
- SGの棚卸し
- アカウントID/PASSの扱い
- IAMの手動管理
- policy simurator便利
- アプリケーションに脆弱性が会った時の対応
- freeeは今までセキュリティインシデントがない
- Security Monkey使ってみたい
- Google Auth Proxy
@m_mizutani : Attack on AWS, ec2 + honeypot
@nekogeruge_987 : セキュリティの設定、どこまでやってますか？
- 現場感あるアンケート満載！
- SGで行った制限をiptablesでも行う方が意外と多いのが印象的でした
宮崎さん : IAMでの権限設定をひたすらがんばっている話
- 全てのアカウントでIAMを使ってる
- がっちり権限を制限している
- 敵は * (e.g. ec2:*)
- IAM運用のbest practiceをぜひ知りたい！
VyOS Users Meeting Japan #2 に行ってきた
http://vyosjp.connpass.com/event/9667/ に参加してきました。今回は、vyos/build-ami をメンテナンスしている trickv さんが上海から来日されたということで開催されました。
VyOSについてはこちら: http://vyos.net/wiki/Main_Page
メインセッション
VyOS 1.1.0 and NIFTY Cloud New Features @higebu
Tweetとか写真禁止のがちらほら
- VyOS1.1.0 released (http://vyos.net/wiki/1.1.0/release_notes)
- experimentalで VXLAN / DMVPNが入った
- Litium branchが出た。新機能はここにpull req
- 試すなら IaaSの上で
- Nifty Cloudで新機能
- private LAN
- Router
- VPN gateway: Managed L2TPv3にも対応している。独自で拡張している。Storm controlなど(ebtables Nifty cloud original)
- (Un)managed L2TPv3 対応
- Managed L2TPv3、 xl2tpdをmanaged にするパッチを公開予定。ebtablesのstormcontrolとか追加。ebtableshは開発は止まっていてnftables
- macアドレスを通すか、ライフタイムやマルチキャスト、バースとしたときにどれだけ通すかを設定。独自拡張が入っているためOSSにしにくい。。。
- 自宅のRX1200とNifty Cloudを接続。家のRX1200からクラウドのインスタンスにIPアドレスをふったり、接続のdemo
VyOS VXLAN @upaa
About vyos/build-ami @trickv
こちらのコントリビュータ: https://github.com/vyos/build-ami
- VyOSが日本で盛り上がってる http://www.google.com/trends/explore?hl=en-US&q=vyatta,+vyos&cmpt=q&content=1*q=vyatta%2C%20vyos&cmpt=q
- MitelのNWをつないでるルータの話 (Confidentialなので会場だけで)
- Ansibleを使ってAMIを作成
- Rackspace / GCP / Azureなどに対応したい
- Packer対応とかも
- Need Help!
Kauli SSPにおけるVyOS導入事例とおまけ @SatchanP
- http://kau.li/ でのVyOS使用の事例
- Connection 4億件の通信 per day 全てVyOSを通過してる
- 80%がショートパケット
- Peek trafic 500Mbps / 150k pps
- SSP Handmade Serversをラックに詰め込みまくり
- NUMAはOFF / 1coreサーバにしている
- circular bufferは闇雲に多くすると遅延する
- Intel NICのBuffer溢れが発生した。ポーリング間隔とキューを調整
- CPU Affinityの設定
- conntrack
- IP masqueradeでは大事
- メモリ消費するので注意
- conntrack周りのtimeoutは短くしまくった
- Serverいっぱいあるので無慈悲に短く
- マイクロバーストトラフィックはnono-secでの出来事。SWがパケットを一瞬で捨てる悩みのたね
Debian JessieでVyOSをビルドする話、vyos-cfg-zabbix-agentの話（仮）@hiroysato
資料: http://hiroyuki-sato.github.io/vyos-user-meeting-japan-2/#/
- 前回のsqueezeでビルドする話
- pbuilder/cowbuilderを教えてもらった
- ソーシャルデバッグの話
- 特定環境下で起こる不具合をソーシャルデバッグ
- Zabbix agent for VyOS
- Zabbix agent command for VyOS (https://github.com/hiroyuki-sato/vyos-cfg-zabbix-agent)
LT
単位時間あたりの新規 NAT session 数の最大値を測ってみた
- VyOS 10万セッションのNATでも動く
- 単位時間あたりのセッション数は？
- TCPreplayを使った
- 20,000ppsあたりまではエラーなし。30,000ppsくらいからエラーが出始めた
- サイト作った Tcpreplay - pcap ファイルの書き換えと再送信ユーティリティ
まとめ
今回も深いお話で非常に勉強になりました。VyOSをプロダクションでヘビーに使っている事例お増えてきて機能もドシドシ追加されているので、試してみるのはいかがでしょうか。
久しくVyatta / VyOS 触っていないので触ってみなければ。
AWS Casual Talks#3に参加した
AWS Casula Tlaks#3に参加してきました。AWS Casual Talks #3 on Zusaar
2回目までは主催していたのですが、今回から主催をCookpadの星君に移して初めての開催でしたが、過去を超えてくる濃い・本気の内容ですごく良かったです。色々忙しい中ありがとうございます！
簡単にまとめると
メインセッション
@yoshiori Elastic Transcoder でウキウキ動画配信
クックパッド料理動画 を作った話。オンプレ環境で大容量・高トラフィックな配信環境を作った時の話しとAWSで作った際の話。オンプレ環境で実現する場合はクリアしなければいけない課題をAWSのサービスでどうクリアしたかという話でした。Elastic Transcoderの実用事例を聞けた貴重な機会でした。
@myfinder 僕らの AWS 移行記
オンプレ環境からAWSに完全移行した際のお話で、オンプレで使っていたものをAWSに移行する際にどう変えて移行を実施したか、非常に勉強になる話でした。AWSは完全にオンプレで実現出来ることをそのまま実現することは出来ないので、AWSベースな考えやシステム設計にしていくことになるのですが、何を使って何を使わないか、その判断の基準など非常に勉強になりました。
Managedサービスのセグメントを分けたり、Default VPCを使わなかった話など今後参考になる方多いのではないでしょうか。mackerelはAWSに親和性高いですね。
資料: https://github.com/myfinder/aws-casual-3
資料の中で出ている、docker repositoryの話は
AWS Solutions Architect ブログ: Amazon S3をDockerプライベートレポジトリにしてAWS ElasticBeanstalk環境にデプロイ です！
@imai_factory ナウい Kinesis とか DynamoDB の話 (仮)
本舗初公開のDynamoDBのパーティショニングの話を公開しました。DynamoDBはProvisioningされたスループットをどうパーティションで割り振るかや、Unitを下げた時にどういう動作をするか今まで公開されませんでしたが、今回ついに公開されました。
スループットを下げた際に、パーティションのマージは行われず、ホットパーテションの問題が起こる可能性がありますが、こちらはスループット設計時にベースunitを指定し、バースト分に関しては今まで通りスループット向上をするという方法で問題無いかと思います。この辺の話が外で公開出来るようになったことで、DynamoDBのスループット設計やスループット増減戦略が行い易くなったのではないでしょうか。詳細は今後聞いていただければお手伝い出来るところかと。
Kinesis Client LibraryもPython版がでたり進化してますね。
LT
@takipone 参考にならないAWSに関するブログの書き方の話
AWSのサービスUpdateに追従してBlogを書いて頂いている、裏話。あまり今まで語られることがなかったので新鮮でした。
朝起きてまずTwitterでJeff Barrや日本で早く情報をキャッチアップしている方々のTweetを確認するということでしたｗ
なるべく情報を早く深く出していけるように頑張らねば…
@yoshidashingo VPC by Default 時代のアクセス制御
Default VPCがリリースされて久しいですが、アクセス制御をどうするか、皆さん気になっているところだと思いますが参考になったのではないでしょうか。
アクセス制限はAWSのサービスでもそれぞれ異なる方法があり、出来ること出来ないことなどもあるので難しいのですが、きちんと設計して安心・安全な構成を。
@myfinder Redshift vs BigQuery
こちらはよく聞かれる質問ですが、LTでも話がでた、しっかりテーブル設計をしてクエリをしっかり設計してクエリを投げるのであれば、Redshift。しかしRedshiftおじさんが必要。そうでなく、そこまで複雑でないクエリならBQと、しっかりと要点抑えられたLTでした。内容的には同意で、ストリームアップデートなども考えると性能特性などをみて適材適所ですね。気軽にビックデータ系のサービスが使えるようになったのはすごいことだなぁと改めて思いました。
@kani_b Fight Against POODLE
POODLE対応の話。SSLv3を切るという対応がいいと言われていますが、実環境での難しさとAWSで対応を探った話。CloudFrontとELBも実は対応完了しております。
@sgwr_dts DSLネタかDynamoDBネタ (仮)
DynamoDBの前にキャッシュ置くやつー というところで耳が痛い話でしたが、参考になるところが多かったのではないでしょうか。
確かにDynamoDBは読み書きスループットが大きくなってくると値段が上がってしまうのですが、この辺はDynamicDynamoDBで増減させたり、ある一定量以上であれば、Reserved Capacityを使うことで値段が下がるかと。
今回のRW10,000unitsだと、Reserved CapacityでUpfront入れて月30万円位になるでしょうか。(http://aws.amazon.com/jp/dynamodb/pricing/)
そして、DynamoDBとredis/fluentdの合わせ技のRedy、書き込みに遅延は出てしまいますが、redisを同一VPC内に置くことでhit時の読み込みLatency軽減期待できそうです。
Blog:
DynamoDBの前にキャッシュを置こうとした話 - so what
S3とCORS
最近、AWSのサービスも少し様変わりしてきて、インフラレイヤーから、アプリレイヤーまで幅広くサービスが出てきています。SDKも充実してきていて、デバイスやブラウザから直接AWSサービスにアクセスして、S3にデータをUploadしたり、DynamoDBにデータを入れたり、Kinesisにログを流し込んだりなどなど今までサーバをかえして行っていた処理が突き詰めればサーバレスで行えるようになってきました。
もちろん、データを受け取って整形など複雑な処理を行いたいという場合には今まで通りAPIサーバなりを用意する方法になるかと思います。
ここで一つ問題になるのが、認証周りかと思います。例えば、ブラウザやデバイスから直接S3にデータをUploadしたり読み出したりするアプリがあった場合、S3にアクセスするための認証情報をセットする必要があります。このキーの管理はなかなか難しいところがありますが、今までだとTVMと呼ばれるIdentity Brokerを用意して一時的なキーを払い出すという方法がありました。今だと、先日独自認証プロバイダにも対応したAmazon Cognitoを使うことで簡単に実装出来ます。Congnitoは認証だけでなく、デバイス間でのデータ同期なども備えているため是非試してみてはいかがでしょうか。
実はCognitoはデバイスアプリだけで無く、Javascript SDKでも動作するようになりました
Use Amazon Cognito in your website for simple AWS authentication - AWS Developer Blog - Mobile
window.fbAsyncInit = function () { FB.init({ appId: 'xxx' }); FB.login(function (response) { AWS.config.region = 'us-east-1'; AWS.config.credentials = new AWS.CognitoIdentityCredentials({ AccountId: 'xxxxxx', RoleArn: 'arn:aws:iam::xxx0:role/Cognito_FBTestAuthRole', IdentityPoolId: 'us-east-1:xxxxxxxxx', Logins: { 'graph.facebook.com': response.authResponse.accessToken } }); fbUserId = response.authResponse.userID; console.log("FB ID: " + fbUserId); AWS.config.credentials.get(function(err) { if(!err) console.log("Congnito Identity Id: " + AWS.config.credentials.identityId); else console.log(err, err.stack); }); s3 = new AWS.S3(); // Uploadとか }); }; };
こんなかんじで、FBのアカウントと連携して作れます。このへんは今回の本題では無いので、詳細は省略します。
本題
画像なり動画なり大きなデータをブラウザから直接S3にUploadしたいという場合、S3に対してCORSの設定をすることになりますが、一点だけ注意点があります。
Bucketを作成してすぐにCORSを設定してJavascript SDK経由でアクセスすると、CORSが効いていないよなエラーが表示されて、リクエストが失敗します。
なぜかというと、ChromeだとDeveloper Consoleに以下のような出力が出ています
XMLHttpRequest cannot load https://BucketName.s3.amazonaws.com/?prefix=facebook-xxxx. The request was redirected to 'https://BucketName.s3-ap-northeast-1.amazonaws.com/?prefix=facebook-xxxx', which is disallowed for cross-origin requests that require preflight.
見てわかると通り、S3のエンドポイントのリダイレクト(s3共有ぽいURLからリージョンスペシフィックなURL)が起こっています。このリダイレクト先がCORSを引き継いでいないため失敗しています。
これはしばらくまつとリダイレクトされなくなり、CORSも効きアクセスが成功します。
もし、新規Bucketでうまくリクエストがいかないなぁという時に確認してみてはいかがでしょうか。
おまけ
CORSは以下のような感じでBucket Properties->Permissions->Edit CORS Configurationで設定します。
AllowedMethodは許可するものを選んでください。
<?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <AllowedMethod>PUT</AllowedMethod> <AllowedMethod>POST</AllowedMethod> <AllowedMethod>DELETE</AllowedMethod> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration>
また、CORSとは違いますが、Bucket PolicyでこのFacebookのこのユーザIDの人は自分のバケットだけ操作出来るというIAMで使える変数もあるのでご活用ください。
IAM Policy Variables Overview - AWS Identity and Access Management
T2インスタンスがでたので簡単に性能をみてみた
昨日、EC2の新instance familyでT2シリーズが出ました。
今まで、t1.micro/m1.smallとか言われてたシリーズの現行版で、General Purposeにカテゴリも変更されています。
リリースは以下の記事
http://aws.amazon.com/blogs/aws/low-cost-burstable-ec2-instances/
http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html
置き換えは
t1.microをt2.microへ m1.smallをt2.smallへ m1.mediumをt2.mediumへ
という感じです。
特徴としては、CPU(ECU)がバーストするということです。
リリースにも書かれている通りのアルゴリズムでバーストします。
また、特徴として、HVMだけ受け付けるようになり、CPUも Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz が使用されています。
普段は負荷が少ないけど、ある時間のみCPUをおもいっきり使用する様なケースに置いて有用なインスタンスだと思います。
先日発表されたSSD EBS (gp2)とあわせることで、起動時の速度EBSで、処理の速度向上をt2のバーストで行なうことで、起動や処理速度の向上が期待できます。
バーストを見てみた
t2.micro or t1.microでAmazon Linux を使ったUnix Benchをしてみました。実行中はバーストが常に起こる状態です。結果をわかりやすくするため、microを使いました。
CPU 0: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (5000.2 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
10:05:14 up 10 min, 1 user, load average: 0.06, 0.05, 0.05; runlevel 3
------------------------------------------------------------------------
Benchmark Run: Tue Jul 01 2014 10:05:14 - 10:33:19
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 35848981.6 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4529.7 MWIPS (10.0 s, 7 samples)
Execl Throughput 5337.1 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1159756.7 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 327710.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3648669.1 KBps (30.0 s, 2 samples)
Pipe Throughput 2117176.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 384038.3 lps (10.0 s, 7 samples)
Process Creation 17517.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 7047.2 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 970.8 lpm (60.0 s, 2 samples)
System Call Overhead 2707725.1 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 35848981.6 3071.9
Double-Precision Whetstone 55.0 4529.7 823.6
Execl Throughput 43.0 5337.1 1241.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 1159756.7 2928.7
File Copy 256 bufsize 500 maxblocks 1655.0 327710.4 1980.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 3648669.1 6290.8
Pipe Throughput 12440.0 2117176.4 1701.9
Pipe-based Context Switching 4000.0 384038.3 960.1
Process Creation 126.0 17517.4 1390.3
Shell Scripts (1 concurrent) 42.4 7047.2 1662.1
Shell Scripts (8 concurrent) 6.0 970.8 1618.0
System Call Overhead 15000.0 2707725.1 1805.2
========
System Benchmarks Index Score 1813.3
CPU 0: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz (3600.0 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
10:05:28 up 8 min, 1 user, load average: 0.68, 0.22, 0.10; runlevel 3
------------------------------------------------------------------------
Benchmark Run: Tue Jul 01 2014 10:05:28 - 10:33:29
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 20450227.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2382.0 MWIPS (9.9 s, 7 samples)
Execl Throughput 1034.8 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 190620.7 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 49930.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 637706.3 KBps (30.0 s, 2 samples)
Pipe Throughput 275945.7 lps (10.0 s, 7 samples)
Pipe-based Context Switching 52613.4 lps (10.0 s, 7 samples)
Process Creation 785.0 lps (30.1 s, 2 samples)
Shell Scripts (1 concurrent) 771.1 lpm (60.3 s, 2 samples)
Shell Scripts (8 concurrent) 59.9 lpm (60.1 s, 2 samples)
System Call Overhead 97154.5 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 20450227.0 1752.4
Double-Precision Whetstone 55.0 2382.0 433.1
Execl Throughput 43.0 1034.8 240.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 190620.7 481.4
File Copy 256 bufsize 500 maxblocks 1655.0 49930.0 301.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 637706.3 1099.5
Pipe Throughput 12440.0 275945.7 221.8
Pipe-based Context Switching 4000.0 52613.4 131.5
Process Creation 126.0 785.0 62.3
Shell Scripts (1 concurrent) 42.4 771.1 181.9
Shell Scripts (8 concurrent) 6.0 59.9 99.8
System Call Overhead 15000.0 97154.5 64.8
========
System Benchmarks Index Score 250.9
CPU CreditとCPU Usage
CloudWatchで見ることができます。オレンジがt1.micro / 青が t2.microです。
Creditを使いきってみた
見て分かる通り、バースト中でCPUを100％使える状態から、クレジットが減少してきてt2.microのベースラインである10%に綺麗にキャップされていく様子が見れると思います。
サーバ内ではstealの割合が上昇していき、90% stealという状態になりました。実際に使えるのが10%ということですね。
System Benchmarks Index Score は 3回の平均で700程度と落ち込み、10%に完全にキャップされた状態では、t2.microでunix benchが完走しない事もありました。
クレジットは1分ごとに各インスタンスタイプ毎に決められた割合で復活していきますので、バーストを必要としない状態になったら徐々に回復していきます。
リリースやドキュメントにもある通り
t2.micro - 144 (6 CPU Minutes / hour * 24 hours) t2.small - 288 (12 CPU Minutes / hour * 24 hours) t2.medium - 576 (24 CPU Minutes / hour * 24 hours)
まで貯めることが出来ます。(6 CPU Minutesなどが1分間の回復量です)
JAWS DAYS 2014で「これで最強のAWSに」のセッションをやりました
JAWS DAYS 2014のセッションとして、これで最強のAWSにというセッションをやりました。 Twitterなどの反応はこちらに2014/03/15 JAWS DAYS 2014 - 『これで最強のAWSに』セッション #jawsdays #最強のAWS - Togetterまとめ まとめて頂いています。各セッションの発表資料はタイムテーブルからリンクがあります。
このセッションは、普段AWSを使っている方々をお呼びして、使っているからこそわかるAWSのイマイチなところ、イケてるところ、バッドノウハウ、こうしたら・こうなったらもっと良くなるのにという話をして頂きました。当日はOFAのMilesさんと、AWS SAの大谷さんにもご参加頂き、直接要望や実際のところどうやったらいいのさ？という事を直接伝える場があったらなと思い企画しました。(企画の大本は実はre:Invent2013開催中のラスベガスの会場にて生まれました。その時、堀内さんが撮った写真がこちら)
AWSでできること出来ないことをきちんと理解して、出来ないことをどうカバーするか、こういう機能があれば更に便利にシンプルに使えるというところが伝わればと #jawsdays #最強のAWS
— con_mame (@con_mame) 2014, 3月 15AWSのイベントでざっくざっく切り込んで行くスタイルをやるのは3回目くらいですが、いつ突っ込まれるか毎回ヒヤヒヤものです。
また、120分ぶっ通しのセッションかつ、裏ではImmutable Infrastructureのパネルが行われており、セッションにどのくらい人が入ってくるか不安でしたが、実際始まってみると、常時立ち見が出る状態で、終了後やTwitterなどの反応・会場での人気投票でもかなり良い評価をいただけていたようでした。
これは本当に発表していただいた3名とMilesさん・大谷さんのおかげと思っています。(自由に話していただこうと、かなりふわっとざっくりとしたお願いしかしておらず申し訳なかったです…)
発表資料
ぜんぶ AWS でやらないワケ by DeNA 坂本 卓巳 さん
発表で印象だったのは、オンプレとAWSを透過的に扱えるツールがあること。オンプレ・AWSを同じように扱えるというのはとても大事なことだと思っていて、AWSを使うとなっても運用方法が大きく変わってしまうと、それだけでも結構なコストになってしまうと思います。また、MHAに比べるとRDSのフェイルオーバーはまだまだ時間がかかるというのは自分も同じ悩みを持っていて、Milesさんが言うには今はもっと時間短縮されているとのことですが、それでも数分のオーダー。。 re:InventでもRDSチームとMTGする機会があったのですが、そこでも切実にお願いしておいた案件です。
AutoScalingやRDS、CloudWatchなどオンプレと同じ構成で自前で運用しなくてもフルマネージドサービスとしてAWSには存在しますが、ブラックボックなため障害時の切り分けやAWSならではの制約・制限に引っかかり実はすんなり移行できない併用しにくい部分というのが存在します。コストにしても。
既存の環境でツールなどが作りこまれてると、AWSに移行したとしても、自前でコントロールしたほうが案外運用しやすかったりするものです。
発表を通して、同じ悩みを抱えてる…と思っていました。
What makes AWS invincible by フリークアウト 岩尾 はるか さん
50ms or dieのフリークアウトさんの発表。EC2インスタンス同士で低遅延で通信するというオプションが無いのは確かにそうで、Placement Groupが要件を満たせそうな感じがしますが、HPC向けインスタンスなどのハイスペックインスタンスしか使えないです。AWS内部のlatencyのゆらぎもここまでシビアな要件になるとかなり影響がでるのだろうなと聞いていました。
後は、AWSの管理周りの話。Management Consoleでポチポチやることもあるけれど、UIが絶妙な感じで、Stopの上にTerminateがあったり、CLIでもRoute tableやRoute53などいじる場合やEC2インスタンスを起動するだけでもわかりにくいオプションを使わないといけない。そして、AWSはインフラをコードで管理できるが、Sandboxなどのテスト環境が無いのが辛いという話は会場やTwitterでも共感の声が多かったように思います。(オプション指定が難しすぎる…ラッパーなどを書けばいいのでしょぅが…)
Mileさんが一番食いついたのは、Record & Play機能が欲しいというもので、Management Consoleの操作を記録して、コードなどにしてくれる機能。これは確かに欲しい…
Sandboxに関しては、Eucalyptusが使えるとMilesさんからの回答がありました。CLIならdru runがあると。IAMも少し前にポリシーをテスト出来る様になったのですが、EC2もクリティカルな場所はdry runだけでなく、テストしやすい方法があると良いなと思っています。
複数VPCでのベストプラクティス by クルートテクノロジーズ 宮崎 幸恵 さん
サイト毎に1アカウント1VPCという使い方。これはお金周りなどなどの事情によるものだそうで。。そして、今70VPCを管理しているという構成図を見てかなり驚きました…そして、それぞれのVPCがオンプレや監視を行ってるVPCと通信していて、通信にはVyattaにてVPN、ルーティングやNATが行われているという、そしてVPCも頻繁に増えたり消えたりと頭蕩けそうな感じでした…
AWS公式にVPCのIGWがVPC間ルーティングをサポートしてくれるとスッキリとした感じになると思うのは凄く同意です。後、事前アンケートでも多かった、サブネットのリサイズ。最初スモールスタートやオンプレとNW周りを合わせるために小さくサブネットを切ってしまうと、インスタンスが増えてきたり、ELBが増えると(ELBは5-6個IPアドレスを消費します)IPアドレスが足りなくなってしまい、リサイズが出来ないので、VPCなりサブネット作りなおして引っ越しとなってしまします。技術的に難しいのはわかるのですが、欲しい機能の1つです。
最初からどかんと大きくサブネットを切るというのも手なのですが、そうするとサブネット数が少なくなるのでこちらも中々悩ましいところです。
まとめ
今回、登壇をお願いした方々は、ソーシャルゲーム・アドテク・エンタープライズ系と三者三様で、AWSに求める部分もそれぞれの事業形態の観点で違っていて、聞いていて非常に参考になったと同時に、JAWS DAYSを通して、AWSは本当に様々な業界や形態で使われているというのを改めて実感しました。
それぞれの要求に答えていくことは非常に難しいことだとは思いますが、その中でも共通して共感できる部分というのも少なくは無く、その部分に関して直接中の人にフィードバックしてお伝え出来てよかったかなと思っています。
Milesさんも、発表を聞きながらgood b っていう場面が何回もあったり、それいいね！ということもありました。それぞれの質問にも丁寧に答えて頂き、セッション終了後も色々話して頂きました。
AWSを使い始めよう・使い始めたばかりという方には、こういうこともあるのか、とか、普段バリバリ使ってる方には、それやっぱありますよねーみたいな感じ思っていただければ嬉しいところです。
事前に行った、バッドノウハウアンケートでも予想以上の回答があり、いくつかは直接答えていただけました。こちらもアンケートにご協力いただいた方々ありがとうございます！
ちなみに、事前アンケートで一番多かったのは、EBSの性能周りで、容量を大きく(500GB以上)そして、IOPSも高く設定して、事前に全領域にddなどで書き込んでおかないと性能が…とかもう少し1本でIOPS出したいというものでした。
他にも、CloudFormationのテンプレートの仕様やInfini bandやRDMA使いたいなどもありました。意外とバッドノウハウ集まってます…
監視についても色々ありましたが、Milesさん的にはNagiosやzabbixなどと組み合わせて、CloudWatchを使って、CloudWatchはAWS内部で取得しているメトリクスを見るのに使うのに適してるとのこと。(最小監視間隔が1分で2週間しかログを保持しないためその辺の要望が多かったです) 監視も適材適所ですね。
AutoScalingに関しては、CloudWatchに頼らず、自前のスクリプトでMax/Minのキャパシティを調整するのがいいんじゃないかなぁとのことでした。
次に突っ込んだ話は、 AWS Casual Talks#2 で！
そして、こういうバッドノウハウなどのあまり外には出してない・出しにくいノウハウ共有は別の機会にまたガツンとやりたいと思っています！
ありがとうございました！
気軽なMySQLバージョンアップ
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！
このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。
MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。
新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。
検証
実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流してみるのが確実かつ影響を確認しやすいと思います。しかし、これは結構難しかったりします。実際に発行されるクエリを集めるのが特に面倒。。
アプリケーション規模が小さい間は、少しアプリケーションを改修して発行されるSQLをログにだすとか、 general logを有効にしてDB側で記録してしまうというのも手なのですがパフォーマンスにも影響が出てしまう可能性があるのと、アプリケーション規模やアクセス量が大きくなるとログ量がすさまじいことになってしまいかねません。(収集するサーバへのリクエスト振り分け率を落としても。。)
また、せっかく集めてもアプリケーションの機能追加などは検証中も随時行われているため、新規発行クエリをまた集めないといけません。
これはカジュアルじゃないですね。
実際に移行してみた
先日とある大きなサービスの大きめのDBバージョンアップ(メジャーバージョン2アップ)とパラメータ調整を行った際に実際に使用した方法をご紹介します。(5.6へじゃないですよ…)
まず、DBのバージョンアップを行う場合以下の様な方法で行うと思います。
左側が旧環境、右が移行先です。
現在稼働している旧Slaveの下にバージョンアップ後に使う新DB masterをSlaveとして、更にその下にSlaveをぶら下げます。(新Master達はバックアップやSnapshotから複製していきます。dumpからimportした場合でない場合は、mysql_upgradeを忘れずに)
切替時は、一旦メンテナンスモードなどに入れて、レプリケーションを切り、アプリケーションの接続先を変更します。
これで完了となります。
Kage
メンテナンス前の検証やパフォーマンス・チューニングではKageを使用しました。
Kageについては
cookpad/kage · GitHub
Kageを使う時にやっておくと便利なこと - まめ畑
move to mysql5.6 // Speaker Deck
を見ていただくとわかりやすいですが、リクエストを複製して、2つのバックエンドサーバにリクエストを送り、レスポンスのdiffを取ったり、新アプリケーションのパフォーマンス計測を気軽に行うことが出来ます。ユーザさんへのレスポンスはオリジナルサーバからのものが返却されるため、カジュアルにテストを行うことが出来ます。
今回は、以下の様な構成でテストを行いました(赤線はバックアップ用の設定経路です)
本番環境のproxyの下にKageサーバを配置し、その下に旧DB群につながっているアプリケーションサーバと、新DB群に繋がるアプリケーションサーバを配置しました。
新旧DBはレプリケーションされていますが、書き込みテスト時にレプリケーションエラーが発生することもあるので、最初はSELECTが殆どのページを先にテストしてしまい、その後全ページをテストするという方針で行いました。また、新Masterへ書き込みが起こるのでレプリケーションエラーも発生しますが、このテストでは、アプリケーションへの影響・パフォーマンス・オプティマイザまわりを見たいため、こちらは基本的に無視をしてレプリケーションを行うようにしました。
このテストでは、Kageサーバのパフォーマンスによっては全てのリクエストをさばけないため、Kageサーバへのリクエスト振り分け率は下げてあります。
そのためDBへの負荷は既存の本番サーバよりも低くなるため、負荷テストなどは別途行います。
そのためのSQLリストを取得するためにもこの構成は有用で、テスト用のサーバからはレスポンスがユーザさんへ返却されないため、SQLのログをアプリケーションサーバで出すように気軽に出来ます。DBのパラメータ・チューニングもカジュアルに出来ます。
この構成では検証用アプリケーションサーバもデプロイターゲットにしておくことで、新機能などで新規発行されるSQLもリアルタイムに受け付けることが出来るため、常に最新の状態を検証でき、サイトの動線やユーザさんの行動もシュミレーションではなく実際のものが取れるため、推測ではない実際のトランザクションをで検証が行えます。
ご存知の方も多いと思いますが、もし、新DBが5.6でGTIDをONにするぜ！！というナウいヤング方は、この構成ではONに出来ません。(レプリケーションクラスタ全体でONにする必要があるため)そのため、アプリケーションサーバの設定を切り替えるタイミングでレプリケーションを切るので、ここでGTIDをONにしてmysqlを再起動し有効後、CHANGE MASTERでauto positionをONにします。
Kageの設定
Kageの設定はすごく簡単で、ざっくりと
require 'kage' require 'diff/lcs' def compare(a, b) # 超カンタンにdiffとってますが、もう少し詳細にとって、fluentdなどで飛ばしてためたりする diffs = Diff::LCS.diff(a.split(/\n/), b.split(/\n/)) diffs.each do |diff| diff.each do |line| p line end end end Kage::ProxyServer.start do |server| server.port = 8090 server.host = '0.0.0.0' server.debug = false server.add_master_backend(:production, 'production-app', 80) server.add_backend(:newdb, 'newdb-app', 80) server.client_timeout = 15 server.backend_timeout = 10 server.on_select_backends do |request, headers| # GETかつpathが/adsで無いものだけ比較 # ここではads決め打ちだが、リクエスト毎に内容が変わる可能性のあるpathは正規表現で除外 if request[:method] == 'GET' && request[:path] != '/ads' [:production, :newdb] else [:production] end end # [:production, :newdb]が選ばれた際にここでdiffとったりログったり server.on_backends_finished do |backends, requests, responses| compare(responses[:production][:data], responses[:newdb][:data]) end end
この様な感じで、2つのバックエンドサーバのレスポンスを比較したりしています。
また、newdb-appではログレベルも変えてあり、負荷試験用にSQLログを出力させています。
compareのところで、bodyだけ取り出しレスポンスを比較したり、速度を見たりします。
その辺はお好みで色々いじれます。
もちろん、MySQLサーバのエラーログも忘れずに見ましょうね！
まとめ
MySQLのバージョンアップは色々と気を使う部分が多く、アプリケーションの開発速度が速いとさらに影響範囲を調べるのが手間になってしまいます。
しかし、Kageを使うことで、リアルタイムにクエリ状況を確認出来るため少しは手間が減るんじゃないでしょうか？
バージョンアップ以外にも、チューニングなどにも活用できます。
もちろんバージョンアップの際は
MySQL :: MySQL 5.5 Reference Manual :: 2.12.1.1 Upgrading from MySQL 5.1 to 5.5
や
MySQL Server 5.6 defaults changes (Supporting MySQL)
など、Changelogもちゃんと見ましょう！
明日は @kazeburo さんです！
