Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

クラウド環境におけるWebアプリケーションの正しい作り方(for Perl users)

1,433 views

Published on

YAPC::Hokkaido 2016 Sapporo

Published in: Technology
  • Be the first to comment

クラウド環境におけるWebアプリケーションの正しい作り方(for Perl users)

  1. 1. Masashi Terui @ marcy_terui I’m a Developer and Cloud Architect. I’m a Remote-Mulit-Worker at Serverworks Co., Ltd. and Freelance. I’m a member of GCPUG and JAWS-UG. I’m a best cloud engineer in Hokkaido!!(でありたい) I’m around 30 years old. I’m a father of my son and daughter. 2
  2. 2. 3
  3. 3. 4 クラウドの真の価値って何? ステップで学ぶポイント クラウドとはなんだったのか? まとめ
  4. 4. 5
  5. 5. 6 サーバコストが下がる? 開発コストが下がる? 運用負荷の軽減? 柔軟なスケールによる機会損失低減?
  6. 6. 7 サーバコストが下がる? 短期的には下がる。中長期的には同じか高くなる。 大企業で「数十%削減」とか言ってることがあるけど、
 あれは移行のタイミングで再設計した効果だったり、
 元々HWベンダーに保守費をかなり払ってたりする例 経営的にはTCOが下がって変動費に変わって嬉しいことも
  7. 7. 8 開発コストが下がる? 少なくともHW調達やNW等の構築コストは下がる クラウド特有のサービスや特性についての学習コスト アプリケーション開発コストが下げられるかどうかはやり方次第
  8. 8. 9 運用コストが下がる? 少なくともHW保守はしなくて良い 仮想サーバはOS以上は自己責任 マネージドサービスと仲良くすると劇的に下げられるが 学習コストはある
  9. 9. 10 柔軟なスケールによる機会損失低減? クラウドの明確なメリットではある ただし、その恩恵を受けられるかどうかはアプリケーション次第 なので、この辺を重点的に喋ります
  10. 10. 11
  11. 11. 12
  12. 12. 13 クラウドの真の価値は? インフラ調達や需給の調整が劇的に早く・楽に インフラがビジネスの足を引っ張らなくなる ボトルネックがアプリケーションに移ったら効果が薄れる
 (パフォーマンスの考え方と一緒)
  13. 13. 14
  14. 14. 15 アプリケーション開発の世界は、
 他者への依存を強めることで発展してきた歴史がある フルスクラッチ→フレームワーク・ライブラリ クラウドもこの流れのインフラ版 インフラを他社に依存することで新しい価値にフォーカスする この流れを突き詰めていくとServerlessに繋がる
  15. 15. 16 
 

  16. 16. 17
  17. 17. 18
  18. 18. 19 

  19. 19. 20
  20. 20. 21
  21. 21. 22 または
  22. 22. 23
  23. 23. 24 

  24. 24. 25
  25. 25. 26 

  26. 26. 27 スケールアップには限界がある CPUはどちらかというとコア数が大事 高速化 ≒ キャパシティ向上 アプリケーション・ミドルウェアチューニング
  27. 27. 28
  28. 28. 29 c4.8xlarge 36vCPU 60GB $2.122/1h r3.8xlarge 32vCPU 244GB $3.192/1h 高い 変更しにくい(停止を伴う) 大きくなるほど性能を使い切るのは難しい
  29. 29. 30
  30. 30. 31 Perlはシングルスレッド・同期IO マルチプロセスで複数のリクエストを捌く シングルプロセス非同期IO(Node.jsとか)の場合は逆 コアが少ないと専有されたら死亡・・・ 重たいクエリ バッチ処理 バグ(無限ループ等)
  31. 31. 32 コアが増えても1コア当たりの性能は変わらない スケールアップで高速化はたかが知れてる スペックが変われば適切なミドルウェアの設定も変わる コアが多いと有効に使い切れない可能性
  32. 32. 33
  33. 33. 34 処理時間が半分になれば単位時間あたりの処理数は約2倍になる 1リクエストの処理に1秒かかるのは遅いと思いますか? 特定の遅いページがあるのは問題 リクエストが集中するとあっという間に全体が詰まる バランス良く高速化が必要
  34. 34. 35 

  35. 35. 36 Apache + mod_perlをpreforkで動かすパターン MaxClientsとか大事だけど限界がある 1ページ見るためにアセットをたくさん取得しなければならない ↑をpreforkで捌くのが問題で必然的にプロセス過多になる
  36. 36. 37 Nginx + Plackが理想 Event driven web server Proxy Cacheは超強力 Cookieで制御したりもできるからかなりの範囲で使える 複雑化するのでご利用は計画的に
  37. 37. 38 Apache + event_mpm + mod_proxy + Plackもアリ Event driven web server .htaccessが使える mod_perlみたいにApacheの処理にフックするのは無理
  38. 38. 39 CDNを導入する 拡張子等でキャッシュ有無を決めれば、
 動的サイトでも大抵問題にならない クラウドだと通常の通信もアウトバウンド通信料がかかり、
 CDNを使っても大差なかったりするので積極的に使うと良い
  39. 39. 40 ここを解決すると性能が一気に上る場合が多い 語りだすと長くなるので省略 とりあえずできるだけ新しいバージョンを使おう @yoku0825 さんの発表を聞きましたよね? :-) MySQLはアホの子という時代は終わりつつある
  40. 40. 41 何はともあれSlow query logを取ろう long_query_time = 0.1 log-queries-not-using-indexes pt-query-digest便利
 → Slow query log(以外も可)の集計・ランキング
  41. 41. 42 実行計画の見方を知る(↓の意味が分かるくらいにはなっておこう) type/ALL, type/index DEPENDENT SUBQUERY UNCACHEABLE SUBQUERY Using temporary Using filesort
  42. 42. 43 キリがないのでインフラ目線でこれくらいはやっとけってやつ DB等のコネクションのSingleton実装 ロック粒度の見直し(MySQLの変態なロック機構を意識する) N+1問題
 → 特にクラウド環境では地理的分散(Multi-AZ)時に大きな問題になる
  43. 43. 44
  44. 44. 45
  45. 45. 46 ステート(セッション)共有・キャッシング リードレプリカ ファイストレージ バッチ処理
  46. 46. 47
  47. 47. 48 Memcached, RedisなどのインメモリKVS DBの問い合わせ結果や加工済みデータをキャッシュする 読み書きの多いSessionデータの格納 大抵は消えても良いはず(無かったら再作成的な) 冗長化だけが目的ならDBでもOK PerlにもDBにセッション入れるモジュールありますよね (PHPで)自作したこともあるけどそんなに難しくない
  48. 48. 49 RedisとMemcachedは併せて語られることが多いが別物 Memcachedの方が運用が楽 本当に永続化しないといけないか考えよう Redisは多様なデータ型やデータ操作という観点で選ぶ Sorted set など Increment, Decrementなど アトミックなデータ操作、Pub/Subなど
  49. 49. 50
  50. 50. 51 DB読み込みの分散 重いクエリの分割(集計バッチ系など) 冗長化 できれば2台以上ほしい レプリカ追加や再作成時にマスターに触らなくて済む
  51. 51. 52 Master, ReadReplicaのコネクションは明示的に使い分ける SQL見て切り替えるみたいな実装もあるけど、整合性とか色々大変 フェイルオーバー時に接続先を連動して切り替える VIP(使えないクラウドが多い、擬似的に利用する方法とかはある) Domainベース NIC付け替え ReadReplicaの接続先振り分け マネージドなInternal LBがあるならそれを使う HAProxyなどで冗長化頑張るか個々に入れるとかもアリ(要自動化)
  52. 52. 53
  53. 53. 54 基本だけど、複数台構成では共有する必要がある NFSは単一障害点になるからダメ 運用で死ねるからダメなやつ GlusterFS, s3fs等 オブジェクトストレージをAPIで操作するのが一番確実 一時的な認証でクライアントに直接アクセスさせたりする手も PerlはSDK用意されてないことが多いけど。。。
  54. 54. 55
  55. 55. 56 複数台構成における悩みの一つ 冗長化が難しい バッチ専用サーバというリソースの無駄 その定期バッチほんとうに必要ですか? オンライン処理からキューイングしてバックエンドで処理できないか? 夜間バッチはリソースが固定なので空きの多い夜間にという発想
 → リソースが柔軟に変更できるクラウドではどうなの?
  56. 56. 57 マネージドサービスの活用 CloudWatch Events Azure Scheduler AppEngine scheduled task AWS Batch → New!!
  57. 57. 58
  58. 58. 59
  59. 59. 60 スケールアウト構成のやつを確実に実行していれば基本大丈夫 GlusterFS使っちゃうとか微妙なことをするとここで困る 運用の変化(ここが大きい) サーバプロビジョニング アプリケーションデプロイ サーバメトリクスとログの収集・集約
  60. 60. 61
  61. 61. 62
  62. 62. 63 テンプレート化 VMイメージ Dockerコンテナ cloud-initなどによる起動時の自動構成変更 コード化 シェルスクリプト, Dockerfile Chef, Puppet, Ansible, Itamae など
  63. 63. 64
  64. 64. 65 自動で増減する、台数が固定ではない、対象が変わる Blue/Green deployment ローリングデプロイ オートディスカバリ Pull型デプロイ
  65. 65. 66
  66. 66. 67 サーバが消えるとそこに載っているログも消える 複数台のどこで発生したログか追うのは難しい 収集と集約 サーバ単位よりも役割単位で見れると良い 可視化が重要
  67. 67. 68 自動サーバが増減する環境では必然的にエージェント型 監視ミドルウェアの運用がしんどい問題 時系列DBの運用がしんどい問題 サービスの活用
 NewRelic, Stackdriver, Mackerel, Datadog etc…
  68. 68. 69 収集 rsyslog Fluentd, CloudWatch Logs Agent 集約・可視化 Elasticsearch + Kibana MongoDB(Capped collection) + Rockmongo, mongo-express オブジェクトストレージ(保管用) BigQuery(分析用)
  69. 69. 70
  70. 70. 71 RDBとNoSQLは使い分け それぞれ得意なデータ構造や操作がある NoSQLで失敗する例は大抵RDBの置き換えをしようとして失敗する それぞれが得意な領域だけオフロードする DBの種類が増えてもマネージドに寄せれば運用負荷は軽減できる トランザクションが本当に必要かどうかは一考の価値がある JOINができない、結果整合性だからといって本当に使えないのか?
 レプリケーションとシャーディングをしたMySQLも同じでは?
  71. 71. 72
  72. 72. 73
  73. 73. 74
  74. 74. 75 
 

  75. 75. 76
  76. 76. 77
  77. 77. 78 クラウドにおける普遍的な概念や思想を知る Design for Failure, Twelve-Factor App などなど Cloud Design Pattern, Reference Architecture などなど APIやサービスの特性 制約を知る NWや物理的な制約・ルール セキュリティの考え方、認証・認可、権限管理
  78. 78. 79
  79. 79. 80
  80. 80. 81
  81. 81. 82
  82. 82. 83 クラウドの真の価値は時間と手間の短縮 パフォーマンスもクラウド活用もボトルネックを作らないことが大事 思想や制約を受け入れることでパフォーマンスが上がる(性能も時間も) クラウドはインフラのフレームワークと考えると良いかも 困ったら相談してください :-)
  83. 83. 84 明日です!(もう満員だけど、少しだけ拡張するかも?)
 https://serverless.connpass.com/event/43745/

×