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

1. AWSを利用して
DevとOps
の間を考える
2013/12/07
Junichiro Ueno / @jun116
開発BAKUFU!!「アジャイル、Ruby、AWS三つ巴戦」
面白法人カヤック 2Fスペース

2. http://devlove-kamakura.doorkeeper.jp/events/7226

3. Junichiro Ueno
上野 潤一郎
Community :
DevLOVE
!
Company :
クラスメソッド株式会社
AWSソリューション部
!
twitter : @jun116
facebook : junichiro.ueno

5. 技術ブログ
Developers.IO
!
http://dev.classmethod.jp/
!
AWSの情報も豊富

6. Devとして
開発時に考えること

7. 計画
設計
技術
インフラ

8. 計画
設計
技術
インフラ

9. AWS利用以前
インフラ ＝ 箱

10. 用意されたものを利用
場合によっては
リリース環境不明

11. 本番環境相当ではない
ステージング環境
• テスト
• パフォーマンス調整

12. AWS利用
インフラ ≠ 箱

13. SQS
•
EC2
•
SES
RDS
• SNS
S3
DynamoDB
•
•
•
•

14. サーバだけではない

15. Devとして
AWSを利用して
どんな環境を構築
するのかを考える

16. 最初の視点は
開発工数を減らす

17. 例えば
•
•
•
S3
データの堅牢性と信頼性
SES
安価、高い信頼性
SQS
シンプル、拡張性、信頼性

18. 信頼できるサービス
に機能をまかせる
(余分な開発を削減)

19. 次の視点は
開発時の
コストを減らす

20. 本番はRDSを想定
開発時は
ローカルDB

21. EC2
帰宅時にインスタン
スを落とす
(出勤時に起動)

22. コストと逆だが
•
•
開発者1人毎に
専用インスタンス
専用バケット

23. 開発時に
運用環境を想定する

25. 開発を意識
↓
環境を意識
↓
コストを意識
↓
環境を修正

26. 開発するものを
どう公開するか

27. 静的なサイト

28. •
Apache
•
Amazon EC2
•
•
HTML
JS
CSS

29. 構成
EC2
m1.small
使用量
100%/月
月額 $ 64.42

30. 構成
EC2
t1.micro
使用量
100%/月
月額 $ 19.77
無料枠利用 $ 0.00

31. •
•
Amazon S3
•
HTML
JS
CSS

32. 構成
S3
ストレージ 1GB
!
月額 $ 0.10
無料枠利用 $ 0.00

33. 開発したものは同じ
デプロイ先は異なる

34. •
何が違う？
AWS利用料

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

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

37. •
•
何が違う？
AWS利用料
Ops側の運用費

38. サービスサイト
•
大量アクセス数を意識

39. 単純に構築

40. Amazon EC2
RDS DB
Instance

41. 大量アクセスゆえに
•
•
RDSの負荷
リードレプリカを並べる
!
コスト増大

42. 構成を変えてみる

43. Amazon EC2
DynamoDB

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

45. Amazon SQS
DynamoDB
Amazon EC2
Amazon EC2

46. SQS
キューの追加に制限がなく、
データロストがない(冗長構成)
低コストで利用可能
→ 急激な負荷に耐えつつ
ある程度パフォーマンス保証
!
※ メッセージは重複します

47. Worker
SQSからデータを取得し、
DynamoDBとRDSを更新
→ データ取得量を調整が可能
瞬間ピークにも焦らなくて済む

48. RDSじゃないの？

49. DynamoDB
更新が速いのはメリットだが、
読込パフォーマンスの速さも抜群！
→ 読込IOPSは比較的安価

50. DynamoDBを
データ読込に活用

51. 参照系として利用
•
RDSのリードレプリカを並べるより安価
→ リードレプリカは起動も遅い
•
パフォーマンスの調整も簡単
→ IOPSを調整すれば良い
•
なにより圧倒的な信頼性
→ 分散型で強い整合性を持つ

52. RDSも併用可能
•
•
永続化させたいデータ
検索させたいデータ

53. 環境構築

54. Chef?

55. AWSなら
CloudFormation

56. Stack単位で
テンプレート管理

57. すべてテンプレートで管理
•
•
•
開発環境
ステージング環境
本番環境

58. 何度でも
環境構築可能

59. 環境変更(update)も
CloudFormation
で行うのが良い！

60. なぜ
!
今の環境を
テンプレートから
読み取ることもできる

61. あくまで一例

62. AWSを利用
し始めた結果

63. 開発の役割が
増えた！？

64. •
•
Dev
コスト意識
運用意識

65. 開発時から
公開に向けて考える

66. それって
開発が運用も行う？

67. それでは開発は
回らなくなる！

68. だから
運用は運用に

69. だから
運用に必要なもの
はなんだろう？

70. Dev
から
Ops

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

72. Ops
から
Dev

73. どんな構成？
EC2が落ちると
どうなる？
復旧方法は？

74. 実際は
開発スケジュール
が・・・

75. だから

76. Dev
!
← ここ
!
Ops

77. 環境構築をサポート
•
•
コストを意識した構築
→ 環境改善
運用とのやりとり
→ 開発の思い込みを解消

78. こういうポジション
の存在が必要になる
のではないか！

79. いままで
!
開発したもの
を提供する

80. これから
!
運用環境を含め
開発・提供する

81. まとめ

82. インフラ ＝ 箱
からの脱却

83. AWS
アプリケーションサービス
• SQS、SES、SNS
を活用することで
信頼性、堅牢性を担保

84. 最初の視点は
開発工数を減らす

85. 次の視点は
開発時の
コストを減らす

86. さらに
開発時に
運用環境を想定する

87. 運用時の
コストも減らす

88. 結果
Devは変わる
Opsも変わる(はず)

89. そんな組織
をサポートしていく

90. DevとOps
の間から
(本当は間じゃないけど)

91. Thank you
for listening!
Lets us make new cloud modeling together!