Embed Size (px)
Citation preview
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
こんばんは
近藤うちお> GMOペパボ所属 > 技術基盤チーム > 福岡支社勤務
> Fukuoka.rb > RailsGirls Fukuoka #1 総合雑用/コーチまとめ
興味> Ruby / Golangを少々 > Fluentd / Norikra > Puppet / Docker > Hashicorp tools > OpenStack
http://www.slideshare.net/udzura/hashicorp-tools
7 years old Rubyist> Rails 2.1.0 ごろからのルビースト(2008 ~) > Rubyをこじらせて著作あり > Web+DB Press Ruby連載(2012 ~ 2014) > パーフェクトRuby (2013) > パーフェクトRails (2014)
RailsGirls Fukuoka #1
http://blog.railsgirls.jp/post/128691554417/rails-girls-fukuoka-1
Thanks! E-Zuka Rails!!
ペパボ
minne
minne> 150万の作家さん > 300万DLのアプリ > 全ロールで100台オーバーのインスタンス
とにかく 大規模ウェブサービス
TV CM
CM打ち出し前> サーバ増やすぞ！！と言われても…… > 簡単にはサーバを増やせない状態 > IaaSに乗っていればスケールする、というわけではない
“– http://docs.komagata.org/5304
“ちゃんとAWSを使いこなせず 中途半端なオンプレミス崩れみたいな ドブ環境をたくさん見てきた”
クラウド脳で インフラを改善する話
クラウドな アーキテクチャの基本
12 factors app
VI. Processes Execute the app as one or more stateless processes
IX. Disposability Maximize robustness with fast startup and graceful shutdown
サーバの 「状態」を剥がすmaking stateless
サーバが持っている状態> 見方によるが、以下が考えられる > データベース > セッション/キャッシュ > ユーザのアップロードするファイル > 設定 > ログ > サーバのメトリックス/監視項目
サーバが持っている状態> 見方によるが、以下が考えられる > データベース > セッション/キャッシュ > ユーザのアップロードするファイル > 設定 > ログ > サーバのメトリックス/監視項目
ひとつひとつ 剥がしていく
データベース セッション キャッシュ
いかにも開発途上なアーキテクチャ
いかにも開発途上なアーキテクチャ
Railsアプリ、 データベース(MySQL)、
セッションが 1台のサーバに同居
※ あくまでも例です
これをこうします
これをこうしますRailsアプリケーション （フロントエンド）
データベース （バックエンド）
MySQL
memcached
ロールの分割> この構成で重要なのは > appサーバはサービスのロジックのことだけ > MySQLはデータベースのことだけ > memcachedはセッションとキャッシュのことだけ
それぞれに ちゃんと集中させる
問題が限定される
🔥 🔥🔥
🔥 🔥
問題が限定される
🔥🔥
🔥
✅
✅
ボトルネックを、個別に強化できる> 多くの場合、それはappサーバ（コンピュート）となるだろう > cf. minneのappサーバは…55台 now > 時には70,80台にもなる
> 逆に、DBがボトルネックなら、 appサーバに関係なく 個別にスケールアップ/スケールアウトできる
こうなるための大前提
アーキテクチャの整備
といっても これくらいは基本中の基本
ユーザが アップするファイル
オブジェクトストレージのご紹介> ファイルやフォルダを「オブジェクト」と捉える > 大きなオブジェクトを、比較的低価格に、高い可用性を もって保管し、またそのファイルをユーザに簡単に配布 できるようなサービスを「オブジェクトストレージ」と 呼んでいる
> 例: > AWS - S3 (Simple Storage Service) > OpenStack - Swift (c.f. ConoHaのオブジェクトストレージ)
c.f. ペパボのBayt> s3互換のオブジェクトストレージ
ユーザがファイルをアップする
そのままオブジェクトストレージへ
cf. Ruby on Railsの paperclip gem
httpで配布もできる
こうなるとダメな理由
こうなるとダメな理由
❓こっちのサーバにどうやって
画像を配る？
CDNを使おう> 画像は、（基本的に）不変なもの > 不変なコンテンツを圧倒的スケールで配るための仕組み＝CDN > Contents Delivery Network
> ユーザが上げなおした場合→URL自体変えよう
CDNの様子最初は元サーバ（オリジン）
から取得する
二度目以降は、（キャッシュが切れるまで）CDNで直接返す
さらに クラウドらしく
画像を変換しよう> ユーザがアップした画像は、サムネイル化したり、様々な加工が必要となる。
> 全部事前に作るのは大変 > mruby+ImageMagickで動的に変換！ > コードネーム「okara」
> 毎回変換するわけにはいかないので、フロントにCDNを立てる
okaraの様子
二度目以降は、同じようにCDNで直接返せる
URLにパラメータなどいろいろ含む
元画像はストレージから
パラメータを 元に拡大縮小
考えることが また減った
設定
設定＝サーバそれぞれ固有？> サーバ作業をsshログインして行うとする > ログインした後の中での作業は、基本的に見えない、見えづらい…… > historyや手順書を頼りにする？ > サーバAとBとで設定が微妙に違う…… > nginx.20151123.conf.bak ……
コード化する
構成管理ツール> サーバの設定、パッケージ、ミドルウェアなどをを、特定の状態に収束させるためのツール
> 専用の言語（Puppet, Ansible）や、Ruby DSL（Chef, Itamae）などで記述する
構成管理ツールのメリット> サーバの状態をコードに落とせるので > 誰が実行しても同じ状態になる > 変更を管理できる > GitHubだのプルリクだのナウい感じでサーバ開発ができる
誰が実行しても 同じ状態のサーバ
＝サーバの差異がなくなる> コマンド一発で、常に、確立された同じ手順で構築できるようになる
> また、サーバに何が入っているかの全貌も把握できる > cf. Serverspec > サーバの状態をテストし、またRSpecで書ける
minneの場合> 基本的にすべてのサーバロールをPuppetで書いている > 3,400 commits > 700 PR > CIをしたり、壊れない工夫をする
レビューもできる
設定の差異をなくすには> まとめると > 構成管理ツールを軸にする > 新しいサーバを、そのレシピを元に構築する > また、構成について、運用者でコードレビューなどで共有していく
> 逆に、管理されていない箇所を極力なくす
“–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.”
ログ
ログの分散> それぞれのサーバの production.log > grepしてエラーを探すとか…… > 容量問題とか……
> サーバの数が増え続け、厳しくなる運用調査 > 一つのエラーの調査に50台のサーバにログイン？ > アクセスはサーバをまたいでいるけど？
> サーバを簡単に落とせない > 消えてはいけないログの存在
Fluentdとは> ログコレクタ/アグリゲーションが専門のデーモン型ミドルウェア
> 「どこからログを集めるか」と「そのログをどこに保存するか」のそれぞれを抽象化する
> Rubyでプラグインを書くことができる
つまりどういうこと？> いろいろと出てくるログは、とりあえず Fluentdに投げてしまえば、後から考えることができる
> ファイルなど、いろいろな方法でログを取得できるので、既存のシステムを変えずにそのまま導入もしやすい
概要図
> from Fluentd に Treasure Data がコミットする理由
基本的な構成
🔄
基本的な構成
🔄クライアント
アグリゲーター
最終的な 蓄積先
基本的な構成
🔄
クライアントは、 個々のアプリケーションのログを
拾って送りつける
基本的な構成
🔄
集計処理は アグリゲーターに 一手にお願いする
基本的な構成
🔄
データの貯め先は、 PaaSやオブジェクトストレージなど 可用性の高く、運用が楽なところへ
※ 雑に閲覧できるよう ファイルにも貯める
（あくまでも運用のため。永続性は保証しない）
最初は雑でいい> Fluentdはプラガブルだから > 最終的バックエンドを変えたい→わずかな設定で🆗 > ログの取り元が増えた→わずかな設定で🆗
> プラグインを作るのも、そこまで敷居は高くない。Rubyでガッと。 > テストツールなどが揃っていて楽。
貯めたデータは> 今のところよく使うのは、運用上の調査 > サーバをまたいでアクセスログが並ぶので
> 今後は、TD上のデータを集計したり、なんやらかっこいいことをしたいところ > そのための新しいツール（貯め先）の追加もFluentdは楽で良い
監視/メトリクス
監視とは> サーバがあるべき状態になっているか定期的に確認し、おかしかったら関係者に知らせる仕組み
> 一種のテストとも解釈できる > 二値監視と、メトリック監視がある > 二値＝生きてるか死んでいるか > メトリック＝数字をとって、異常値や変動を見る
監視は 「職人芸」？
職人の技> 従来の監視は中央集権型が多い > サーバが増えるごとに中央サーバにも設定追加 > 動的なサーバ構成だと……
> Nagios、Zabbixなど、多機能だが設定項目も多い。
> コード化しても限界がある
どうせ職人なら クラウド職人になりたい！
mackerelとは> はてな社の監視のためのSaaS > もともと自社のためのものを事業化 > https://mackerel.io/
mackerelの特徴> エージェント型 > 中央サーバは、SaaSやけん、気にしなくていい
> カスタムメトリックスが柔軟に設定できる > APIも公開
> サーバ側に入れるエージェントはオープンソース > https://github.com/mackerelio/
セットアップの楽っぷり> エージェントをインストールして、サービスを起動するだけ。 > これでグラフができる > エージェントは、rpmとdebが用意済みなので、ほとんどのLinux Serverでさっくり入れられるはず
> やはり、中央サーバを自分で用意しなくていいという気楽さは大きい
APIがある is 大事> クラウドの世界では、サーバは動的に追加されるし、動的に削除される。
> 追加削除のたびに設定を書き換えたくない！ > APIがあれば： > 追加時の登録も自動でできる > Terminate時の退役も自動に。
通知> Monitorsで設定。Nagiosのプラグインを再利用したり、任意の値でアラートを出したり。
Slack連携が👍
プラグインの自作> Goの実装が公開されているので、それを参考にできる
> 最近はmruby-cliで作るのも流行ってる？
楽＋かゆい所に手が届く
cf. 監視のSaaS> 他には、Datadogが有名どころ > Newrelicなども入る
まとめ
クラウド脳とは？> サーバー＝資産 から > サーバー＝コンピュート へ > 考え方をスイッチさせること
コンピュートとは> 直訳で、「計算」 > サーバに何かしらのインプットをしたら、副作用なく、何かしらのアウトプットを返す
> cf. 関数型プログラミング
HTTPはステートレス> 対義語: ステートフルなプロトコル(FTPなど) > 必要な情報は、基本全部リクエストの中にある > なのでスケールさせやすい どのサーバが
受け取ってもいい
ウェブサービスなので> 当然、状態は持っている。 > 大事なのは、どこがストレージで、どこがコンピュートなのかをきっちり見極めること > ストレージはスケールアップ > コンピュートはスケールアウト
“–「ソフトウェアアーキテクトが知るべき97のこと」より、ニール・フォード
“本質的な複雑さは単純に、 付随的な複雑さは取り除け”
ばーんとサーバを増やすと
楽しい
みんなも クラウドになろう！
[PR]
ランチョン、しませんか> ペパランチョンでお話を（会場でも是非）。 > https://pepabo.com/recruit/pepaluncheon/?fukuoka
