1. AWSを学ぶための取り組み
Serverworks Sonic #1
AWSチーム 柳瀬 任章

2. 自己紹介
柳瀬 任章（やなせ ひであき）
AWSチーム マネージャ
インフラエンジニア
Twitter：@oko_chang

3. わたしの近況
今年4月からチームにリーダーというあだ名の方が
入りました
みんな彼をリーダーと呼びます
社長も彼をリーダーと呼びます
会社ブログのはてブ数は軽く超えられました
現在のチームリーダーはわたしになります

4. おねがい
(;ﾟﾛﾟ)ﾊｯ
これも何かの縁です
みなさま有事の際はわたくしを
どうぞよろしくお願い申し上げます

5. チームについて
これからAWSを使う方のお手伝いを行います
導入支援、移行支援、運用代行
ほぼ一日中AWSとキャッキャウフフするお仕事
『VPC作ってー』『オッケー☆ウフフ』

6. AWSを触ってみて
便利
たくさんサービスあるよね
いろいろ使いこなして相乗効果がある
お客さまには最適なものを使ってもらいたい

7. チームの課題
新機能リリース早すぎ追いつけない
どう使えば良いか分からないのもある
自分ひとりで調べきれない
英語ェ・・・

8. ラクしたい
負荷は分散しよう
手が回らないところは人に調べてもらおう
調べた人が分かりやすく教えてもらおう

9. やっている取り組み
技術ブログで分かりやすく共有
社内勉強会でLT
週次定例会で小ネタ発表
AWS Articles共有会[New!!]
http://aws.amazon.com/articles/
http://blog.serverworks.co.jp/tech/2012/08/10/
best-practices-for-using-amazon-s3/

10. AWS Articles共有会
Amazon RDS DB Parameter Group Deployment Guide
RDSのパラメータグループをどう使い分けるか
変更する場合はなるべくリスクを回避しよう

11. PGの使い分け
PGを複数のRDSで共有 RDSごとにPGを割り当て
変更は全てに影響 変更する場合はそれぞれ

12. PGの使い分け
一つのPGを複数のRDSに割り当て
複数のRDSに変更を適用したい場合に簡単
一つのDBインスタンスの変更が他にも影響
複数のPGをそれぞれのRDSに割り当て
変化の影響を最小限に抑える事が出来る
変更する場合はインスタス毎に変更する

13. PG変更時のリスク回避
1.テスト環境の作成
2.変更点のテスト
3.変更点のデプロイ

14. ①テスト環境の作成

15. ①の手順
本番環境と同じ構成を作成
RDSだからスナップショットから簡単に複製
DBインスタンスのタイプはなるべく同じに
本番環境となるべく近しい環境でテストをする
テスト用のPGを作成
本番環境のPGで既に変更されてるところをリスト化
本番環境と同様の設定をテスト用のPGに適用
テスト環境のPGをテスト用のPGに変更
スナップショットからのリストアはDefaultのPGで起動されます
PGを切り替えた後は必ずインスタンスの再起動を行なって下さい

16. ②変更点のテスト

17. ②の手順
テスト環境のPGを変更する前にパフォーマンステストを実施
Before/Afterを明確にするため
変更したいパラメータの変更を実施
Dynamicなパラメータは即適用
Staticなパラメータは再起動が必要
RDSに接続して変更が行われている事を確認します
SHOW GLOBAL VARIABLES LIKE ‘hogehoge’;
変更した後にRDSが起動しなかった場合は切り戻し
パフォーマンステストを実施

18. ③変更点のデプロイ

19. ③の手順
本番環境RDSのバックアップを取得する
作業前のバックアップはやりましょう
自動バックアップを無効にしてる場合は有効に
事前に切り戻し用のコマンドなどを準備する
切り戻しが発生した場合に素早く対応するため
変更点をデプロイする
動作確認を忘れずに

20. まとめ
リスクを最小限に抑えたPGの使い方を覚えましょう
簡単に複製出来るので変更する場合はテストを必ず
行うようにしましょう
社内外でうまく共有会が出来れば幸せかも

21. それでは今後とも
（わたくしを）
よろしくお願いします！