AWSを利用して

DevとOps
の間を考える
2013/12/07

Junichiro Ueno / @jun116

開発BAKUFU!!「アジャイル、Ruby、AWS三つ巴戦」


面白法人カヤック 2Fスペース
http://devlove-kamakura.doorkeeper.jp/events/7226
Junichiro Ueno

上野 潤一郎
Community :
 DevLOVE
!

 Company :
 クラスメソッド株式会社
AWSソリューション部
!

twitter : @jun116
facebook : junichi...
技術ブログ
Developers.IO
!

http://dev.classmethod.jp/
!

AWSの情報も豊富
Devとして
開発時に考えること
計画

設計

技術

インフラ
計画

設計

技術

インフラ
AWS利用以前

インフラ = 箱
用意されたものを利用
場合によっては
リリース環境不明
本番環境相当ではない
ステージング環境
• テスト
• パフォーマンス調整
AWS利用

インフラ ≠ 箱
SQS

•

EC2

•

SES
RDS
• SNS
S3
DynamoDB

•
•

•
•
サーバだけではない
Devとして
AWSを利用して
どんな環境を構築
するのかを考える
最初の視点は
開発工数を減らす
例えば

•

•

•

S3

データの堅牢性と信頼性
SES

安価、高い信頼性
SQS

シンプル、拡張性、信頼性
信頼できるサービス
に機能をまかせる
(余分な開発を削減)
次の視点は
開発時の
コストを減らす
本番はRDSを想定
開発時は
ローカルDB
EC2
帰宅時にインスタン
スを落とす
(出勤時に起動)
コストと逆だが
•
•

開発者1人毎に
専用インスタンス
専用バケット
開発時に
運用環境を想定する
開発を意識
↓

環境を意識
↓

コストを意識
↓

環境を修正
開発するものを
どう公開するか
静的なサイト
•

Apache
•

Amazon EC2

•
•

HTML
JS
CSS
構成
EC2
 m1.small
使用量
 100%/月
月額 $ 64.42
構成
EC2
 t1.micro
使用量
 100%/月
月額 $ 19.77
無料枠利用 $ 0.00
•
•
Amazon S3

•

HTML
JS
CSS
構成
S3
 ストレージ 1GB
!

月額 $ 0.10
無料枠利用 $ 0.00
開発したものは同じ
デプロイ先は異なる
•

何が違う?
AWS利用料
•
•

EC2の場合
運用監視
トラブル対応
•

S3の場合
特になし
※ 細かい考慮はせず
•
•

何が違う?
AWS利用料
Ops側の運用費
サービスサイト
•

大量アクセス数を意識
単純に構築
Amazon EC2

RDS DB
Instance
大量アクセスゆえに
•
•

RDSの負荷
リードレプリカを並べる
!

コスト増大
構成を変えてみる
Amazon EC2

DynamoDB
DynamoDB
設定したIOPSを超えた瞬間から
急激にパフォーマンスが落ちる
→ 書込IOPSは値段も高い
大量アクセスの書込に利用は
必ずしも向いているわけではない
Amazon SQS

DynamoDB

Amazon EC2

Amazon EC2
SQS
キューの追加に制限がなく、
データロストがない(冗長構成)
低コストで利用可能
→ 急激な負荷に耐えつつ
  ある程度パフォーマンス保証
!

※ メッセージは重複します
Worker
SQSからデータを取得し、
DynamoDBとRDSを更新
→ データ取得量を調整が可能
  瞬間ピークにも焦らなくて済む
RDSじゃないの?
DynamoDB
更新が速いのはメリットだが、
読込パフォーマンスの速さも抜群!
→ 読込IOPSは比較的安価
DynamoDBを
データ読込に活用
参照系として利用
•

RDSのリードレプリカを並べるより安価


→ リードレプリカは起動も遅い
•

パフォーマンスの調整も簡単

→ IOPSを調整すれば良い

•

なにより圧倒的な信頼性

→ 分散型で強い整合性を持つ
RDSも併用可能
•
•

永続化させたいデータ
検索させたいデータ
環境構築
Chef?
AWSなら

CloudFormation
Stack単位で
テンプレート管理
すべてテンプレートで管理
•
•
•

開発環境
ステージング環境
本番環境
何度でも
環境構築可能
環境変更(update)も
CloudFormation
で行うのが良い!
なぜ
!

今の環境を
テンプレートから
読み取ることもできる
あくまで一例
AWSを利用
し始めた結果
開発の役割が
増えた!?
•
•

Dev
コスト意識
運用意識
開発時から
公開に向けて考える
それって
開発が運用も行う?
それでは開発は
回らなくなる!
だから
運用は運用に
だから
運用に必要なもの
はなんだろう?
Dev
から

Ops
SPOFはないよ
運用に必要なツール
とかある?
トラブル時の対応方法
Ops
から

Dev
どんな構成?
EC2が落ちると
どうなる?
復旧方法は?
実際は
開発スケジュール
が・・・
だから
Dev
!

     ← ここ
!

Ops
環境構築をサポート
•

•

コストを意識した構築

→ 環境改善
運用とのやりとり

→ 開発の思い込みを解消
こういうポジション
の存在が必要になる
のではないか!
いままで
!

開発したもの
を提供する
これから
!

運用環境を含め
開発・提供する
まとめ
インフラ = 箱
からの脱却
AWS
アプリケーションサービス
• SQS、SES、SNS
を活用することで
信頼性、堅牢性を担保
最初の視点は
開発工数を減らす
次の視点は
開発時の
コストを減らす
さらに
開発時に
運用環境を想定する
運用時の
コストも減らす
結果
Devは変わる
Opsも変わる(はず)
そんな組織
をサポートしていく
DevとOps
の間から
(本当は間じゃないけど)
Thank you
for listening!
Lets us make new cloud modeling together!
AWSを利用してDevとOpsの間を考える
AWSを利用してDevとOpsの間を考える
Upcoming SlideShare
Loading in …5
×

AWSを利用してDevとOpsの間を考える

713
-1

Published on

開発BAKUFU!!「アジャイル、Ruby、AWS三つ巴戦」発表資料

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
713
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

AWSを利用してDevとOpsの間を考える

  1. 1. AWSを利用して DevとOps の間を考える 2013/12/07 Junichiro Ueno / @jun116 開発BAKUFU!!「アジャイル、Ruby、AWS三つ巴戦」
 面白法人カヤック 2Fスペース
  2. 2. http://devlove-kamakura.doorkeeper.jp/events/7226
  3. 3. Junichiro Ueno 上野 潤一郎 Community :  DevLOVE !  Company :  クラスメソッド株式会社 AWSソリューション部 ! twitter : @jun116 facebook : junichiro.ueno
  4. 4. 技術ブログ Developers.IO ! http://dev.classmethod.jp/ ! AWSの情報も豊富
  5. 5. Devとして 開発時に考えること
  6. 6. 計画 設計 技術 インフラ
  7. 7. 計画 設計 技術 インフラ
  8. 8. AWS利用以前 インフラ = 箱
  9. 9. 用意されたものを利用 場合によっては リリース環境不明
  10. 10. 本番環境相当ではない ステージング環境 • テスト • パフォーマンス調整
  11. 11. AWS利用 インフラ ≠ 箱
  12. 12. SQS • EC2 • SES RDS • SNS S3 DynamoDB • • • •
  13. 13. サーバだけではない
  14. 14. Devとして AWSを利用して どんな環境を構築 するのかを考える
  15. 15. 最初の視点は 開発工数を減らす
  16. 16. 例えば • • • S3
 データの堅牢性と信頼性 SES
 安価、高い信頼性 SQS
 シンプル、拡張性、信頼性
  17. 17. 信頼できるサービス に機能をまかせる (余分な開発を削減)
  18. 18. 次の視点は 開発時の コストを減らす
  19. 19. 本番はRDSを想定 開発時は ローカルDB
  20. 20. EC2 帰宅時にインスタン スを落とす (出勤時に起動)
  21. 21. コストと逆だが • • 開発者1人毎に 専用インスタンス 専用バケット
  22. 22. 開発時に 運用環境を想定する
  23. 23. 開発を意識 ↓ 環境を意識 ↓ コストを意識 ↓ 環境を修正
  24. 24. 開発するものを どう公開するか
  25. 25. 静的なサイト
  26. 26. • Apache • Amazon EC2 • • HTML JS CSS
  27. 27. 構成 EC2  m1.small 使用量  100%/月 月額 $ 64.42
  28. 28. 構成 EC2  t1.micro 使用量  100%/月 月額 $ 19.77 無料枠利用 $ 0.00
  29. 29. • • Amazon S3 • HTML JS CSS
  30. 30. 構成 S3  ストレージ 1GB ! 月額 $ 0.10 無料枠利用 $ 0.00
  31. 31. 開発したものは同じ デプロイ先は異なる
  32. 32. • 何が違う? AWS利用料
  33. 33. • • EC2の場合 運用監視 トラブル対応
  34. 34. • S3の場合 特になし ※ 細かい考慮はせず
  35. 35. • • 何が違う? AWS利用料 Ops側の運用費
  36. 36. サービスサイト • 大量アクセス数を意識
  37. 37. 単純に構築
  38. 38. Amazon EC2 RDS DB Instance
  39. 39. 大量アクセスゆえに • • RDSの負荷 リードレプリカを並べる ! コスト増大
  40. 40. 構成を変えてみる
  41. 41. Amazon EC2 DynamoDB
  42. 42. DynamoDB 設定したIOPSを超えた瞬間から 急激にパフォーマンスが落ちる → 書込IOPSは値段も高い 大量アクセスの書込に利用は 必ずしも向いているわけではない
  43. 43. Amazon SQS DynamoDB Amazon EC2 Amazon EC2
  44. 44. SQS キューの追加に制限がなく、 データロストがない(冗長構成) 低コストで利用可能 → 急激な負荷に耐えつつ   ある程度パフォーマンス保証 ! ※ メッセージは重複します
  45. 45. Worker SQSからデータを取得し、 DynamoDBとRDSを更新 → データ取得量を調整が可能   瞬間ピークにも焦らなくて済む
  46. 46. RDSじゃないの?
  47. 47. DynamoDB 更新が速いのはメリットだが、 読込パフォーマンスの速さも抜群! → 読込IOPSは比較的安価
  48. 48. DynamoDBを データ読込に活用
  49. 49. 参照系として利用 • RDSのリードレプリカを並べるより安価
 → リードレプリカは起動も遅い • パフォーマンスの調整も簡単
 → IOPSを調整すれば良い • なにより圧倒的な信頼性
 → 分散型で強い整合性を持つ
  50. 50. RDSも併用可能 • • 永続化させたいデータ 検索させたいデータ
  51. 51. 環境構築
  52. 52. Chef?
  53. 53. AWSなら CloudFormation
  54. 54. Stack単位で テンプレート管理
  55. 55. すべてテンプレートで管理 • • • 開発環境 ステージング環境 本番環境
  56. 56. 何度でも 環境構築可能
  57. 57. 環境変更(update)も CloudFormation で行うのが良い!
  58. 58. なぜ ! 今の環境を テンプレートから 読み取ることもできる
  59. 59. あくまで一例
  60. 60. AWSを利用 し始めた結果
  61. 61. 開発の役割が 増えた!?
  62. 62. • • Dev コスト意識 運用意識
  63. 63. 開発時から 公開に向けて考える
  64. 64. それって 開発が運用も行う?
  65. 65. それでは開発は 回らなくなる!
  66. 66. だから 運用は運用に
  67. 67. だから 運用に必要なもの はなんだろう?
  68. 68. Dev から Ops
  69. 69. SPOFはないよ 運用に必要なツール とかある? トラブル時の対応方法
  70. 70. Ops から Dev
  71. 71. どんな構成? EC2が落ちると どうなる? 復旧方法は?
  72. 72. 実際は 開発スケジュール が・・・
  73. 73. だから
  74. 74. Dev !      ← ここ ! Ops
  75. 75. 環境構築をサポート • • コストを意識した構築
 → 環境改善 運用とのやりとり
 → 開発の思い込みを解消
  76. 76. こういうポジション の存在が必要になる のではないか!
  77. 77. いままで ! 開発したもの を提供する
  78. 78. これから ! 運用環境を含め 開発・提供する
  79. 79. まとめ
  80. 80. インフラ = 箱 からの脱却
  81. 81. AWS アプリケーションサービス • SQS、SES、SNS を活用することで 信頼性、堅牢性を担保
  82. 82. 最初の視点は 開発工数を減らす
  83. 83. 次の視点は 開発時の コストを減らす
  84. 84. さらに 開発時に 運用環境を想定する
  85. 85. 運用時の コストも減らす
  86. 86. 結果 Devは変わる Opsも変わる(はず)
  87. 87. そんな組織 をサポートしていく
  88. 88. DevとOps の間から (本当は間じゃないけど)
  89. 89. Thank you for listening! Lets us make new cloud modeling together!

×