Masashi Terui @ marcy_teruiI’m a Developer and Cloud Architect.

I’m a Remote-Muliti-Worker at Serverworks Co., Ltd. and Freelance. I’m a member of JAWS-UG and GCPUG.

I’m a best cloud engineer in Hokkaido!!(でありたい) I’m 30 years old. I’m a father of my son and daughter.

2

3

AWSエンジニアの現状

AWSエンジニアの価値

アプリケーションのこととか

DevOpsとはなんだったのか

4

5

AWS Summit Tokyoのメインメッセージ（私見）

2014年「クラウドファースト」

2015年「ニューノーマル」

2016年「もう当たり前だから特になし（たぶん）」

6

AWSJ「市場の拡大期に入った」とパートナー数の増大強化を発表

2016年1月パートナー数　約300→約400

http://www.publickey1.jp/blog/16/post_aws.html

7

この辺

8

9

10

11

12

13

14

固定の償却コストが変動コストに スケールによる大きなコストメリット キャパシティ予測が不要に 速度と迅速性の向上 データセンターの運用と保守への投資が不要に わずか数分で世界中にデプロイ https://aws.amazon.com/jp/cloud/ (クラウド導入のメリットより)

15

16

17

固定の償却コストが変動コストに → 落とせない スケールによる大きなコストメリット → スケールできない キャパシティ予測が不要に　　　　　 → 同上 速度と迅速性の向上　　　　　　　　 → 変化に柔軟ではない DCの運用と保守への投資が不要に 　 → 手がかかる わずか数分で世界中にデプロイ　　　 → デプロイに時間がかかる

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

RDSのデフォルトパラメータは最大公約数

本当に適したパラメータはワークロードによって異なる

ワークロードを知るにはどうすれば良い？

実際に流れているクエリを全て記録して解析する？

38

39

どのようなクエリが多いと予想できるか？

人気ブログサイト

商品数の多いECサイト

DAUの多いソーシャルサービス

社内情報管理系

40

これらの機能はどうやってできている？

ランキング

カテゴライズ

閲覧履歴

お友達機能

商品別売上集計

41

42

想定されるデータ量はどうか？

各機能の利用頻度はどうか？

今後、要求が変化する可能性はあるか？

データの鮮度に対する要求はどうか？（→キャッシュ、バッチ処理）

などなど

43

44

データベースについて

リレーショナルモデル

インデックスの仕組み

実行計画の見方

エンジン毎の特性

アプリケーションについて

SQLの読み方・書き方

データ構造に対する理解

アルゴリズム

DBライブラリに対する理解

45

46

RDBとNoSQLは使い分け それぞれ得意なデータ構造や操作がある NoSQLで失敗する例は大抵RDBの置き換えをしようとして失敗する それぞれが得意な領域だけオフロードする DBの種類が増えてもマネージドに寄せれば運用負荷は軽減できる トランザクションが本当に必要かどうかは一考の価値がある JOINができない、結果整合性だからといって本当に使えないのか？レプリケーションとシャーディングをしたMySQLも同じでは？

47

48

49

50

51

52

53

54

55

56

57

Memcached, RedisなどのインメモリKVS

読み書きの多いSessionデータの格納

中間データの一時的保持

DBの問い合わせ結果や加工済みデータをキャッシュする

58

RedisとMemcachedは併せて語られることが多いが別物 ステート共有とKey-ValueなCacheだけならMemcached（運用も考慮） 本当に永続化しないといけないか考える Redisは多様なデータ型やデータ操作という観点で選ぶ（Sorted set, Increment/Decrement, アトミックなデータ操作、Pub/Subなどなど）

↑を活かせるならRedisを選ぶべき

59

60

基本だけど、複数台構成では共有する必要がある

NFSは単一障害点になるからダメ

運用で死ねるからダメなやつ（GlusterFS, s3fs等）

オブジェクトストレージをAPIで操作するのが一番確実 一時的な認証でクライアントに直接アクセスさせたりする手も

けど、ここの実装コストが見えていないと適切な提案ができない

61

62

63

64

65

66

67

・

68

69

70

71

アプリケーションに合わせたキャッシュ設定 URL, GETパラメータ, Cookieなどの利用状況の把握

キャッシュしやすいアプリケーション設計 分かりやすいURLパターン 動的処理をPOSTやPUTに寄せる などなど

72

73

74

開発と運用のコラボレーション？

コード化・自動化？

インフラエンジニアはコードを書けないといけない？

75

76

固定の償却コストが変動コストに → 落とせない スケールによる大きなコストメリット → スケールできない キャパシティ予測が不要に　　　　　 → 同上 速度と迅速性の向上　　　　　　　　 → 柔軟ではない DCの運用と保守への投資が不要に 　 → 手がかかる わずか数分で世界中にデプロイ　　　 → デプロイに時間がかかる

77

開発と運用のコラボレーション？→ 適切にスケール・変化に強くなるために必要 コード化・自動化？→ 迅速・安全にデプロイするために必要 インフラエンジニアはコードを書けないといけない？→ アプリケーションを理解するために必要

78

79

80

81

まずは「そのまま乗せる」というアプローチは間違っていない 載せないことには結果も何もない いきなりアプリケーションに手/口を出せることは少ない しかし、それをそのままにしておくと成功体験を損なう 信頼関係を築いて、改善していくというアプローチも必要

82

83

「流行りのFWでHello world」して満足してませんか？ 自分が関わるアプリケーションのコードを読んでみる ゼロからデプロイして「面倒だな」と思った所を改善してみる 性能劣化時にSlow Queryを見てSQL発行元まで特定してみる あわよくば直してみちゃう 個人プロダクトを作ってみる（そして、運用してみる）

84

85

クラウドは普及期・幻滅期に入っている

クラウドに適したアプリケーションを載せて成功するのはもう当たり前

そうではないものに対し、さらに踏み込んだ価値を提供する必要がある

DevOpsは結果を出すための手段であって目的ではない

そのために、アプリケーションを知ろう

86

87

88

アプリケーション開発の世界は、他者への依存を強めることで発展してきた歴史がある 低級言語 → 高級言語（コンパイラの進化に伴うマシン語の隠蔽）フルスクラッチ→フレームワーク・ライブラリ クラウドもこの流れのインフラ版 インフラを他社に依存することで新しい価値にフォーカスする この流れを突き詰めていくとServerlessに繋がる

89

90