なれる！Cloud人間 E-zuka tech night @ 2015-11-19

1. GMO Pepabo, Inc.
Uchio Kondo
2015/11/19 E-Zuka tech night⭐
minneで学ぶ！
クラウド脳
https://en.wikipedia.org/wiki/Cumulus_cloud#/media/File:Cumulus_clouds_as_seen_from_an_airplane.JPG

2. こんばんは

4. 近藤うちお
> GMOペパボ所属
> 技術基盤チーム
> 福岡支社勤務
> Fukuoka.rb
> RailsGirls Fukuoka #1 総合雑用/コーチまとめ

5. 興味
> Ruby / Golangを少々
> Fluentd / Norikra
> Puppet / Docker
> Hashicorp tools
> OpenStack
http://www.slideshare.net/udzura/hashicorp-tools

6. 7 years old Rubyist
> Rails 2.1.0 ごろからのルビースト(2008 )
> Rubyをこじらせて著作あり
> Web+DB Press Ruby連載(2012 2014)
> パーフェクトRuby (2013)
> パーフェクトRails (2014)

10. RailsGirls Fukuoka #1
http://blog.railsgirls.jp/post/128691554417/rails-girls-fukuoka-1
Thanks!
E-Zuka Rails!!

11. ペパボ

12. http://tech.pepabo.com/

14. minne

17. minne
> 150万の作家さん
> 300万DLのアプリ
> 全ロールで100台オーバーのインスタンス

18. とにかく
大規模ウェブサービス

19. TV CM

20. CM打ち出し前
> サーバ増やすぞ！！と言われても……
> 簡単にはサーバを増やせない状態
> IaaSに乗っていればスケールする、というわけ
ではない

21. “– http://docs.komagata.org/5304
ちゃんとAWSを使いこなせず
中途半端なオンプレミス崩れみたいな
ドブ環境をたくさん見てきた

22. クラウド脳で
インフラを改善する話

23. クラウドな
アーキテクチャの基本

24. 12 factors app

25. VI. Processes
Execute the app as one or
more stateless processes

26. IX. Disposability
Maximize robustness with fast
startup and graceful shutdown

27. サーバの
「状態」を剥がす
making stateless

28. サーバが持っている状態
> 見方によるが、以下が考えられる
> データベース
> セッション/キャッシュ
> ユーザのアップロードするファイル
> 設定
> ログ
> サーバのメトリックス/監視項目

29. サーバが持っている状態
> 見方によるが、以下が考えられる
> データベース
> セッション/キャッシュ
> ユーザのアップロードするファイル
> 設定
> ログ
> サーバのメトリックス/監視項目
ひとつひとつ
剥がしていく

30. データベース
セッション
キャッシュ

31. いかにも開発途上なアーキテクチャ

32. いかにも開発途上なアーキテクチャ
Railsアプリ、
データベース(MySQL)、
セッションが
1台のサーバに同居
※ あくまでも例です

33. これをこうします

34. これをこうします
Railsアプリケーション
（フロントエンド）
データベース
（バックエンド）
MySQL
memcached

35. ロールの分割
> この構成で重要なのは
> appサーバはサービスのロジックのことだけ
> MySQLはデータベースのことだけ
> memcachedはセッションとキャッシュのことだけ

36. それぞれに
ちゃんと集中させる

37. 問題が限定される
🔥 🔥
🔥
🔥 🔥

38. 問題が限定される
🔥
🔥
🔥
✅
✅

39. ボトルネックを、個別に強化できる
> 多くの場合、それはappサーバ（コンピュート）
となるだろう
> cf. minneのappサーバは…55台 now
> 時には70,80台にもなる
> 逆に、DBがボトルネックなら、
appサーバに関係なく
個別にスケールアップ/スケールアウトできる

40. こうなるための大前提

41. アーキテクチャの整備

42. といっても
これくらいは基本中の基本

43. ユーザが
アップするファイル

44. オブジェクトストレージのご紹介
> ファイルやフォルダを「オブジェクト」と捉える
> 大きなオブジェクトを、比較的低価格に、高い可用性を
もって保管し、またそのファイルをユーザに簡単に配布
できるようなサービスを「オブジェクトストレージ」と
呼んでいる
> 例:
> AWS - S3 (Simple Storage Service)
> OpenStack - Swift (c.f. ConoHaのオブジェクトストレージ)

45. c.f. ペパボのBayt
> s3互換のオブジェクトストレージ

46. ユーザがファイルをアップする

47. そのままオブジェクトストレージへ
cf. Ruby on Railsの
paperclip gem

48. httpで配布もできる

49. こうなるとダメな理由

50. こうなるとダメな理由
❓
こっちのサーバにどうやって
画像を配る？

51. CDNを使おう
> 画像は、（基本的に）不変なもの
> 不変なコンテンツを圧倒的スケールで配るため
の仕組み＝CDN
> Contents Delivery Network
> ユーザが上げなおした場合→URL自体変えよう

52. CDNの様子
最初は元サーバ（オリジン）
から取得する
二度目以降は、（キャッシュが切れるまで）CDNで直接返す

53. さらに
クラウドらしく

54. 画像を変換しよう
> ユーザがアップした画像は、サムネイル化したり、
様々な加工が必要となる。
> 全部事前に作るのは大変
> mruby+ImageMagickで動的に変換！
> コードネーム「okara」
> 毎回変換するわけにはいかないので、
フロントにCDNを立てる

55. okaraの様子
二度目以降は、同じようにCDNで直接返せる
URLにパラメータなどいろいろ含む
元画像はストレージから
パラメータを
元に拡大縮小

56. 考えることが
また減った

57. 設定

58. 設定＝サーバそれぞれ固有？
> サーバ作業をsshログインして行うとする
> ログインした後の中での作業は、基本的に見え
ない、見えづらい……
> historyや手順書を頼りにする？
> サーバAとBとで設定が微妙に違う……
> nginx.20151123.conf.bak ……

59. コード化する

60. 構成管理ツール
> サーバの設定、パッケージ、ミドルウェアなど
をを、特定の状態に収束させるためのツール
> 専用の言語（Puppet, Ansible）や、Ruby
DSL（Chef, Itamae）などで記述する

61. 構成管理ツールのメリット
> サーバの状態をコードに落とせるので
> 誰が実行しても同じ状態になる
> 変更を管理できる
> GitHubだのプルリクだのナウい感じでサーバ開発ができ
る

62. 誰が実行しても
同じ状態のサーバ

63. ＝サーバの差異がなくなる
> コマンド一発で、常に、確立された同じ手順で
構築できるようになる
> また、サーバに何が入っているかの全貌も把握
できる
> cf. Serverspec
> サーバの状態をテストし、またRSpecで書ける

64. minneの場合
> 基本的にすべてのサーバロールを
Puppetで書いている
> 3,400 commits
> 700 PR
> CIをしたり、壊れない工夫をする

65. レビューもできる

66. 設定の差異をなくすには
> まとめると
> 構成管理ツールを軸にする
> 新しいサーバを、そのレシピを元に構築する
> また、構成について、運用者でコードレビューなどで
共有していく
> 逆に、管理されていない箇所を極力なくす

67. “–Tao of Hashicorp (https://hashicorp.com/blog/tao-of-hashicorp.html)
Codification is the belief that all processes should be written as code, stored,
and versioned. Operations teams have historically relied on oral tradition to
pass along the knowledge of how to build, upgrade and triage infrastructure.
But information was easily lost or hidden from the people who needed it
most. Codification of critical knowledge promotes information sharing
and prevents data loss, as any changes to process are automatically stored
and versioned.

68. ログ

69. ログの分散
> それぞれのサーバの production.log
> grepしてエラーを探すとか……
> 容量問題とか……
> サーバの数が増え続け、厳しくなる運用調査
> 一つのエラーの調査に50台のサーバにログイン？
> アクセスはサーバをまたいでいるけど？
> サーバを簡単に落とせない
> 消えてはいけないログの存在

71. Fluentdとは
> ログコレクタ/アグリゲーションが専門の
デーモン型ミドルウェア
> 「どこからログを集めるか」と「そのログをど
こに保存するか」のそれぞれを抽象化する
> Rubyでプラグインを書くことができる

72. つまりどういうこと？
> いろいろと出てくるログは、とりあえず
Fluentdに投げてしまえば、後から考えること
ができる
> ファイルなど、いろいろな方法でログを取得で
きるので、既存のシステムを変えずにそのまま
導入もしやすい

73. 概要図
> from Fluentd に Treasure Data がコミットする理由

74. 基本的な構成
🔄

75. 基本的な構成
🔄クライアント
アグリゲーター
最終的な
蓄積先

76. 基本的な構成
🔄
クライアントは、
個々のアプリケーションのログを
拾って送りつける

77. 基本的な構成
🔄
集計処理は
アグリゲーターに
一手にお願いする

78. 基本的な構成
🔄
データの貯め先は、
PaaSやオブジェクトストレージなど
可用性の高く、運用が楽なところへ
※ 雑に閲覧できるよう
ファイルにも貯める
（あくまでも運用のため。永続性は保証しない）

79. 最初は雑でいい
> Fluentdはプラガブルだから
> 最終的バックエンドを変えたい→わずかな設定で🆗
> ログの取り元が増えた→わずかな設定で🆗
> プラグインを作るのも、そこまで敷居は高くな
い。Rubyでガッと。
> テストツールなどが っていて楽。

80. 貯めたデータは
> 今のところよく使うのは、運用上の調査
> サーバをまたいでアクセスログが並ぶので
> 今後は、TD上のデータを集計したり、なんやら
かっこいいことをしたいところ
> そのための新しいツール（貯め先）の追加も
Fluentdは楽で良い

81. 監視/メトリクス

82. 監視とは
> サーバがあるべき状態になっているか定期的に確
認し、おかしかったら関係者に知らせる仕組み
> 一種のテストとも解釈できる
> 二値監視と、メトリック監視がある
> 二値＝生きてるか死んでいるか
> メトリック＝数字をとって、異常値や変動を見る

83. 監視は
「職人芸」？

84. 職人の技
> 従来の監視は中央集権型が多い
> サーバが増えるごとに中央サーバにも設定追加
> 動的なサーバ構成だと……
> Nagios、Zabbixなど、多機能だが設定項目も
多い。
> コード化しても限界がある

85. どうせ職人なら
クラウド職人になりたい！

87. mackerelとは
> はてな社の監視のためのSaaS
> もともと自社のためのものを事業化
> https://mackerel.io/

88. mackerelの特徴
> エージェント型
> 中央サーバは、SaaSやけん、気にしなくていい
> カスタムメトリックスが柔軟に設定できる
> APIも公開
> サーバ側に入れるエージェントはオープンソース
> https://github.com/mackerelio/

89. セットアップの楽っぷり
> エージェントをインストールして、サービスを
起動するだけ。
> これでグラフができる
> エージェントは、rpmとdebが用意済みなので、ほとんど
のLinux Serverでさっくり入れられるはず
> やはり、中央サーバを自分で用意しなくていいという気楽
さは大きい

91. APIがある is 大事
> クラウドの世界では、サーバは動的に追加され
るし、動的に削除される。
> 追加削除のたびに設定を書き換えたくない！
> APIがあれば：
> 追加時の登録も自動でできる
> Terminate時の退役も自動に。

92. 通知
> Monitorsで設定。Nagiosのプラグインを再利
用したり、任意の値でアラートを出したり。

93. Slack連携が👍

94. プラグインの自作
> Goの実装が公開されているので、
それを参考にできる
> 最近はmruby-cliで作るのも流行ってる？

95. 楽＋
かゆい所に手が届く

96. cf. 監視のSaaS
> 他には、Datadogが有名どころ
> Newrelicなども入る

97. まとめ

98. クラウド脳とは？
> サーバー＝資産 から
> サーバー＝コンピュート へ
> 考え方をスイッチさせること

99. コンピュートとは
> 直訳で、「計算」
> サーバに何かしらのインプットをしたら、副作
用なく、何かしらのアウトプットを返す
> cf. 関数型プログラミング

100. HTTPはステートレス
> 対義語: ステートフルなプロトコル(FTPなど)
> 必要な情報は、基本全部リクエストの中にある
> なのでスケールさせやすい どのサーバが
受け取ってもいい

101. ウェブサービスなので
> 当然、状態は持っている。
> 大事なのは、どこがストレージで、どこがコン
ピュートなのかをきっちり見極めること
> ストレージはスケールアップ
> コンピュートはスケールアウト

102. “–「ソフトウェアアーキテクトが知るべき97のこと」より、ニール・フォード
本質的な複雑さは単純に、 付随的な複雑さは取り除け

103. ばーんとサーバを増やすと

104. 楽しい

105. みんなも
クラウドになろう！

106. [PR]

107. ランチョン、しませんか
> ペパランチョンでお話を（会場でも是非）。
> https://pepabo.com/recruit/pepaluncheon/?fukuoka