第18回 Cloud Foundry輪読会で発表した資料です

1. Cloud Foundry
は、なぜ動くのか

2. @jacopen
Kazuto Kusama
NTT Communications
!
Cloudn PaaSの開発・運用をやっています

3. 最近

6. 質問

7. はじめに
今回の発表、元々は
!
• Cloud Foundryのアーキテクチャ概要に軽く触れる
• V2で変わったところを中心に、少し深く追ってみる
!
という予定でした

8. Open Cloud Summit Japan
とかで喋りました

9. が、概要説明だけで100スライド近くになったので、
今回は深追いするのは諦めました。
!
なので、かなり入門者向けの内容になっています。
!
深追いはまた次回！

10. Cloud Foundryに
Sinatraアプリをデプロイ
$ ls
Gemfile README.md dora.rb
instances.rb logging_service.rb spec
stress_testers.rb
Gemfile.lock config.ru
get_instance_cookie_jars.sh log_utils.rb scripts
stress vendor
!
https://github.com/cloudfoundry/cf-acceptance-tests/tree/master/assets/dora

11. [23:08] jacopen@cape ~/Project/dora ✘╹◡╹✘ (master) cf push dora
Creating app dora in org jacopen / space jacopen-space as admin...
OK
!
Creating route dora.107.22.72.200.xip.io...
OK
!
Binding dora.107.22.72.200.xip.io to dora...
OK
!
Uploading dora...
Uploading from: /Users/jacopen/Project/dora
1.2M, 36 files
OK
!
Starting app dora in org jacopen / space jacopen-space as admin...
OK
（中略）
1 of 1 instances running
!
App started
!
Showing health and status for app dora in org jacopen / space jacopen-space as admin...
OK
!
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: dora.107.22.72.200.xip.io
!
state since cpu memory disk
#0 running 2014-04-21 11:09:25 PM 0.0% 72.2M of 256M 0 of 1G

12. ok
!
[23:09] jacopen@cape ~/Project/dora ✘╹◡╹✘ (master) cf apps
Getting apps in org jacopen / space jacopen-space as admin...
OK
!
name requested state instances memory disk urls
dora started 1/1 256M 1G dora.
107.22.72.200.xip.io

13. cf push

14. この間、CF内では
何が行われていたのか？

15. CFというブラックボックスの
を解こう

16. アジェンダ
Cloud Foundryの仕組みを理解するための3章立て
!
• Cloud Foundryを外から叩いて、中身を推測する
• Cloud Foundryの各コンポーネントの役割を知る
• Cloud Foundryのコンポーネント間通信を知る

17. 今回やらないこと
!
• WardenコンテナやBuildpackなどの解説
• MySQLやPostgresなどのService系の解説
• loggregatorなどの、周辺サービスの解説

18. では始めましょう

19. Cloud Foundryを
外から叩いて
中身を推測しよう 1

20. CF_TRACE=true
[23:49] jacopen@cape ~/Project/dora ✘╹◡╹✘ export CF_TRACE=true
[23:49] jacopen@cape ~/Project/dora ✘╹◡╹✘ cf push dora
!
REQUEST:
GET /v2/spaces/dbf6ed0a-3108-45d8-9c78-a512d5071358/apps?q=name%3Adora&inline-relations-depth=1
HTTP/1.1
Host: api.107.22.72.200.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.0.0-90db382 / darwin
!
!
!
RESPONSE:
HTTP/1.1 200 OK
Content-Length: 107
Content-Type: application/json;charset=utf-8
Date: Mon, 21 Apr 2014 14:49:13 GMT
Server: nginx
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 18dcd4aefdd000506e49c4b5cf739aaa::65195823-dac9-410a-855a-4ef5ba249198
!
{
"total_results": 0,
"total_pages": 0,
"prev_url": null,
"next_url": null,
"resources": [
!
]
}
Creating app dora in org jacopen / space jacopen-space as admin...

21. 調査の CF_TRACE=true
CF_TRACE=trueにすると、cf コマンドが
裏で行っているリクエストを見ることができる。

22. cf pushを覗いてみよう

23. GET /v2/spaces/dbf6ed0a-3108-45d8-9c78-a512d5071358/apps?q=name%3Adora&inline-relations-depth=1 HTTP/1.1
HTTP/1.1 200 OK
!POST /v2/apps?async=true HTTP/1.1
{"name":"dora","space_guid":"dbf6ed0a-3108-45d8-9c78-a512d5071358"}
HTTP/1.1 201 Created
!GET /v2/shared_domains HTTP/1.1
HTTP/1.1 200 OK
!GET /v2/domains?inline-relations-depth=1&q=name%3A107.22.72.200.xip.io HTTP/1.1
HTTP/1.1 200 OK
!GET /v2/routes?inline-relations-depth=1&q=host%3Adora%3Bdomain_guid%3A524ba14d-4d3f-495f-a2c7-a5ed25a70e81 HTTP/1.1
HTTP/1.1 200 OK
!POST /v2/routes?async=true&inline-relations-depth=1 HTTP/1.1
{"host":"dora","domain_guid":"524ba14d-4d3f-495f-a2c7-a5ed25a70e81","space_guid":"dbf6ed0a-3108-45d8-9c78-a512d5071358"}
HTTP/1.1 201 Created
!PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/routes/ed912294-be29-4013-8b1c-735851acee24 HTTP/1.1
HTTP/1.1 201 Created
!PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/bits?async=true HTTP/1.1
Content-Type: multipart/form-data;
HTTP/1.1 201 Created
!GET /v2/jobs/6dd46fe7-40b0-41d1-94aa-dd2ee80fd3b2 HTTP/1.1
HTTP/1.1 200 OK
(queued)
!GET /v2/jobs/6dd46fe7-40b0-41d1-94aa-dd2ee80fd3b2 HTTP/1.1
HTTP/1.1 200 OK
(finished)
!CONNECTING TO WEBSOCKET: wss://loggregator.107.22.72.200.xip.io:443/tail/?app=0e948568-aa90-47e9-a128-9ff3cc680600
!PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600?async=true&inline-relations-depth=1 HTTP/1.1
{"state":"STARTED"}
!GET /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/instances HTTP/1.1
HTTP/1.1 400 Bad Request
{"code":170002,"description":"App has not finished staging","error_code":"CF-NotStaged"}
!GET /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/instances HTTP/1.1
api.107.22.72.200.xip.io と
何かやりとりしてる

24. 分かったこと

25. cf push
Cloud Foundryは、APIを提供している
APIを提供してくれる
何か

26. cf push
cf pushは、APIをいろいろ叩いてデプロイする
APIを提供してくれる
何か
GET xxxx
PUT xxxx
POST xxxx
GET xxxx
アプリを動かす何か

27. アクセス先を調べよう

28. API
api.107.22.72.200.xip.io

29. Application
dora.107.22.72.200.xip.io

30. あれ？

31. APIも、Appも、同じIPアドレス
$ nslookup api.107.22.72.200.xip.io
Server: 192.168.11.1
Address: 192.168.11.1#53
!
Non-authoritative answer:
api.107.22.72.200.xip.io canonical name = api.1jkk1uz.xip.io.
Name: api.1jkk1uz.xip.io
Address: 107.22.72.200
!
$ nslookup dora.107.22.72.200.xip.io
Server: 192.168.11.1
Address: 192.168.11.1#53
!
Non-authoritative answer:
dora.107.22.72.200.xip.io canonical name = dora.1jkk1uz.xip.io.
Name: dora.1jkk1uz.xip.io
Address: 107.22.72.200

32. cf push
アドレスを元にアクセスを分配する
何者かが居る
APIを提供してくれる
何か
アクセス
を
分ける
何かブラウザ
アプリを動かす何か

33. cf scale
$ cf scale -i 3 -m 256M dora
Scaling app dora in org jacopen / space jacopen-space as admin...
OK
cf scaleコマンドで、稼働する「インスタンス数」
「メモリサイズ」などを変更できる

35. cf push
アドレスを元にアクセスを分配する
何者かが居る
APIを提供してくれる
何か
アクセス
を
分ける
何かブラウザ

36. アプリが死ぬとどうなる？

37. dora/sigterm/KILL
sigterm/KILLで、自分自身のプロセスを終了

38. ポートが変わった

39. アプリの死活監視をしている
何かが居る
APIを提供してくれる
何か
アクセス
を
分ける
何か
死活
監視

40. 結果

41. 外から見えるCloud Foundry
APIを提供してくれる
何か
アクセス
を
分ける
何か
アプリを
動かす何か
死活
監視

42. Cloud Foundryの中身(の一部)
Cloud Controller
Router
DEA
Health
Manager

43. Cloud Foundryにおける
コンポーネントの
役割を知ろう ２

44. コンポーネント＝？
Cloud Controller
Router
DEA
Health
Manager

45. コンポーネント＝アプリケーション
Cloud Controller
(Ruby)
Router
(Golang)
DEA
(Ruby)
Health
Manager
(Golang)

46. 全コンポーネントを1VMに集約できる
Cloud Controller
(Ruby)
Router
(Golang)
DEA
(Ruby)
Health
Manager
(Golang)
VM

47. (一般的に)実運用では、
コンポーネントごとにVMを分ける
Cloud Controller
(Ruby)
Router
(Golang)
DEA
(Ruby)
Health
Manager
(Golang)
VM
VM
VM VM

48. それぞれのコンポーネントを
見ていこう

49. Router
Cloud Controller
Router
DEA
Health
Manager

50. Routerとは
URLによって、適切なコンポーネントにアクセスを
振り分けるL7ロードバランサー(のようなもの)
ネットワーク機器の「ルーター」とは違う点に注意。
実体は、Ubuntu上で動く、Goで書かれた
アプリケーション。(Gorouterという)

51. Cloud Controller
Router
DEA
Health
Manager
api.107.22.72.200.xip.io
dora.107.22.72.200.xip.io

52. Cloud Controller
Router
DEA
Health
Manager
api.107.22.72.200.xip.io
dora.107.22.72.200.xip.io
なぜRouterはリクエストの振り先を
知っているのか？

53. Cloud Controller
Router
DEA
Health
Manager
router.register
各コンポーネントが、router.registerという
メッセージをRouterに送る
api.107.22.72.200.xip.ioは
10.244.0.138:9022に送って
dora.107.22.72.200.xip.io
は10.244.0.26:61032に送って

54. Cloud Controller
Router
DEA
Health
Manager
router.register
Routerは、収集した情報を元に
アクセスを分配する
dora.107.22.72.200.xip.io => 10.244.0.26:61032
api.107.22.72.200.xip.io => 10.244.0.138:9022
api.107.22.72.200.xip.io
dora.107.22.72.200.xip.io

55. Cloud Controller
Router
DEA
Health
Manager
router.register
同一URLに複数の振り先でも大丈夫
dora.107.22.72.200.xip.io => 10.244.0.26:61032
dora.107.22.72.200.xip.io => 10.244.0.27:58719
api.107.22.72.200.xip.io => 10.244.0.138:9022
api.107.22.72.200.xip.io => 10.244.0.139:9022
api.107.22.72.200.xip.io
dora.107.22.72.200.xip.io
Cloud Controller
DEA

56. Cloud Controller
Cloud Controller
Router
DEA
Health
Manager

57. Cloud Controllerとは
APIを提供するコンポーネント。
!
• cfコマンド等からアプリケーションの受け取り
• DEAに対してアプリの起動・停止の指示
• Service(データベース等)の作成の指示
!
などなど、Cloud Foundry全体に対しての
コントロールを行う。

58. POST /v2/apps?async=true HTTP/1.1
{"name":"dora","space_guid":"dbf6ed0a-3108-45d8-9c78-a512d5071358"}
HTTP/1.1 201 Created
!
GET /v2/shared_domains HTTP/1.1
HTTP/1.1 200 OK
!
GET /v2/domains?inline-relations-depth=1&q=name%3A107.22.72.200.xip.io HTTP/1.1
HTTP/1.1 200 OK
!
GET /v2/routes?inline-relations-depth=1&q=host%3Adora%3Bdomain_guid%3A524ba14d-4d3f-495f-a2c7-a5ed25a70e81 HTTP/1.1
HTTP/1.1 200 OK
!
POST /v2/routes?async=true&inline-relations-depth=1 HTTP/1.1
{"host":"dora","domain_guid":"524ba14d-4d3f-495f-a2c7-a5ed25a70e81","space_guid":"dbf6ed0a-3108-45d8-9c78-a512d5071358"}
HTTP/1.1 201 Created
!
PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/routes/ed912294-be29-4013-8b1c-735851acee24 HTTP/1.1
HTTP/1.1 201 Created
!
PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/bits?async=true HTTP/1.1
Content-Type: multipart/form-data;
HTTP/1.1 201 Created
!
GET /v2/jobs/6dd46fe7-40b0-41d1-94aa-dd2ee80fd3b2 HTTP/1.1
HTTP/1.1 200 OK
(queued)
!
GET /v2/jobs/6dd46fe7-40b0-41d1-94aa-dd2ee80fd3b2 HTTP/1.1
HTTP/1.1 200 OK
(finished)
!
CONNECTING TO WEBSOCKET: wss://loggregator.107.22.72.200.xip.io:443/tail/?app=0e948568-aa90-47e9-a128-9ff3cc680600
!
PUT /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600?async=true&inline-relations-depth=1 HTTP/1.1
{"state":"STARTED"}
!
GET /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/instances HTTP/1.1
HTTP/1.1 400 Bad Request
{"code":170002,"description":"App has not finished staging","error_code":"CF-NotStaged"}
!
GET /v2/apps/0e948568-aa90-47e9-a128-9ff3cc680600/instances HTTP/1.1
⇐appの作成
⇐domainの取得
⇐routesの確認
⇐routesの作成
⇐appとroutesの紐付け
⇐ソースのアップロード
⇐appを起動

59. DEA
Cloud Controller
Router
DEA
Health
Manager

60. DEAとは
ユーザーアプリを動かすためのコンポーネント。
Droplet Execution Agentの略。
!
CF v2では、ユーザーアプリのStaging作業(Rubyの
bundle installなど)も担当する。
!
DEAはWardenというLinuxコンテナを使い、ユーザー
アプリを動かす(が、今回は触れない)

61. Clientからのソース受け取り
Cloud Controller
Router
DEA
Health
Manager
cf push
Gemfile
lib/
bin/
config.ru
app.rb

62. Staging依頼
(staging.start)
Cloud Controller
Router
DEA
Health
Manager
cf push
Gemfile
lib/
bin/
config.ru
app.rb
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru

63. Golden Packageの保存
Cloud Controller
Router
DEA
Health
Manager
cf push
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru

64. Start依頼
(dea.start)
Cloud Controller
Router
DEA
Health
Manager
cf push
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru

65. Start依頼
(dea.start)
Cloud Controller
Router
DEA
Health
Manager
cf push
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru

66. Cloud Controller
Router
DEA
Health
Manager
cf scale -i 3
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru
DEA

67. Start依頼
(dea.start)
Cloud Controller
Router
DEA
Health
Manager
cf scale -i 3
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru
DEA

68. Start依頼
(dea.start)
Cloud Controller
Router
DEA
Health
Manager
cf scale -i 3
Gemfile
Gemfile.lock
vendor/
lib/
bin/
config.ru
DEA

69. Health Manager
Cloud Controller
Router
DEA
Health
Manager
DEA

70. Health Managerとは
!
ユーザーアプリが、「あるべき姿」になっているか
どうか、監視を行うコンポーネント。
!
最新版は、Goで書かれた「hm9000」

71. インスタンスの突然死
Cloud Controller
Router
DEA
Health
Manager
DEA

72. droplet.exited
Cloud Controller
Router
DEA
Health
Manager
DEA

73. hm9000.start
Cloud Controller
Router
DEA
Health
Manager
DEA

74. dea.start
Cloud Controller
Router
DEA
Health
Manager
DEA

75. dea.start
Cloud Controller
Router
DEA
Health
Manager
DEA

76. 何故かインスタンスが多い場合
Cloud Controller
Router
DEA
Health
Manager
DEA

77. dea.heartbeat
Cloud Controller
Router
DEA
Health
Manager
DEA
3インスタンスのはず
なのに、4つ来た･･･

78. hm9000.stop
Cloud Controller
Router
DEA
Health
Manager
DEA

79. dea.stop
Cloud Controller
Router
DEA
Health
Manager
DEA

80. dea.stop
Cloud Controller
Router
DEA
Health
Manager
DEA

81. それぞれの関係、分かりましたか？
Cloud Controller
Router
DEA
Health
Manager
内部通信
外部からのアクセス

82. Cloud Foundryにおける
コンポーネント間
通信を知ろう ３

83. さっきのこの図
Cloud Controller
Router
DEA
Health
Manager
内部通信
外部からのアクセス

85. Cloud Controller
Router
DEA
Health
Manager
NATS

86. NATSとは
!
Publish-Subscribeモデルの軽量メッセージングシステム
!
Cloud Foundryの生みの親、Derek Collison氏が開発。
Cloud Foundry登場時から存在する、アーキテクチャの
キモになるシステム。
!
元々はRubyで、EventMachineを使って実装されていた。
現在はGoで実装された、gnatsdになっている

87. Publish-Subscribeモデル
Publisher Subscriber
NATS
Subject: foo.bar
Subject: foo.bar

88. Publish-Subscribeモデル
Publisher Subscriber
NATS
Subject: foo.bar
{“message”:“hogefuga”}
{“message”:“hogefuga”}
{“message”:“hogefuga”}

89. Publish-Subscribeモデル
Publisher Subscriber
NATS
Cloud
Controller
DEA
Router
Subject: router.register
{“host":"10.244.0.138","port":9022,"uris":
["api.107.22.72.200.xip.io"]}
Subject: router.register
{“host":"10.244.0.111","port":37902,"uris":
["dora.107.22.72.200.xip.io"]}

90. 全Subscriberが同じメッセージを受け取れる
NATS
Cloud
Controller
DEA
Router
Subject: router.register
{“host":"10.244.0.138","port":9022,"uris":
["api.107.22.72.200.xip.io"]}
Subject: router.register
{“host":"10.244.0.111","port":37902,"uris":
["dora.107.22.72.200.xip.io"]}
Router
Router
Publisher Subscriber

91. もしNATSが無かったら・・・
NATSあり 直接通信
1.Routerを起動
2.Routerはrouter.registerを
subscribe
1.新Routerを管理DBに登録
2.Routerを起動
3.DEA, CCは管理DBを参照
し、Routerリストを取得
4.各Routerに対してメッ
セージ送信

92. Cloud
Controller
Router
DEA Health
Manager
NATSRouter
Router
Cloud
Controller
DEA
DEA
DEA
Cloud
Controller
Cloud
Controller

93. Cloud Foundryのアーキテクチャ
!
• NATSを中心とした、疎結合なコンポーネント間連携
• スケールしやすい！
• 自律分散型システム
• 管理する情報は必要最低限
• セルフヒーリング
• 要は勝手に治る
• SPoF(単一障害点)は排除
• ただし最近までのNATSを除く

94. Cloud Foundry V1と
変わってない？

95. CF v1 と v2 の違い
• 大まかなアーキテクチャは変わっていない
• DEAがDEAngになり、WardenというLinux
コンテナでアプリを動かすように
• いろんなコンポーネントがGoに書き換えられた
• HerokuのBuildpackが使えるように
• APIの互換性は一切無し！

96. 次回はもうちょっと
踏み込んだ内容をやるよ