第60話で、イトはdata centerをserver rackが並ぶ大きな部屋だと決めなかった。
power、cooling、networkのpathを分け、single interruption中もrequestとresponseが続くことを観察した。
facility diagramの上へ、半透明のresource poolが降りてきた。
physical rackの形は奥へ隠れ、手前にはcompute、storage、queue、network、access policyのcontrol cardが並ぶ。
今日のfixture taskは、launch poster十二枚のthumbnailを作ること。
source imageは十二枚。
releaseまで、あと九十秒。
イトはpoolから一番大きいcompute boxを一台だけ引き出した。
「cloudは遠くのserverを借りることだよね。大きい一台に全部入れればいい」
source、generated output、worker program、broad admin keyを、同じboxのlocal shelfへ入れた。
十二枚のtask cardが一度に届く。
runningは1。
queueは11。
イトはcompute sizeを大きくするため、fixtureのreplace holderを引いた。
このfixtureのworker contractでは、replace時にlocal scratchを引き継がない。
new workerは起動した。
しかし最初のgenerated outputはlocal shelfと一緒に消えた。
completed outputは0へ戻った。
broad admin keyだけがnew boxへcopyされた。
releaseまで、あと五十五秒。
一台を遠くへ置いても、それだけでcloudにはならない
イトはempty local shelfと、残った十一枚のqueueを見比べた。
ピコはworker boxへ触れず、resource pool、state shelf、queue、access boundary、usage ledgerを別々に照らした。
イト
cloudなら、machineを大きくすれば全部残ると思った
ピコ
何がreplaceableで、何がpersistentかはservice contractで決まるよ。cloudという名前だけでは決まらない
イト
一台のserverを借りることが中心じゃないの？
ピコ
必要なresourceをpoolからprovisionし、役目が終わればreleaseするmodelとして見よう
この話のresource pool、worker、object shelf、queue、token、scale rule、usage ledgerは、外部cloud accountから切り離した学習fixtureだ。
live resource creation、billing、credential、IAM、production autoscaling、public access、data migrationは行わない。
provider名、product名、price、SLA、region availabilityは固定しない。
見るのは、service requirement、resource abstraction、state、elasticity condition、control scope、measured outcomeの順序だ。
cloud computingは、resource poolへのon-demand access
NIST SP 800-145 The NIST Definition of Cloud Computingはcloud computingを、configurable computing resourcesのshared poolへ、ubiquitous / convenient / on-demand network accessできるmodelとして定義する。
network、server、storage、application、service等を、minimal management effortまたはprovider interactionでrapidly provision / releaseできる。
これは「Internetの向こうにある一台のcomputer」の定義ではない。
physical hardwareはdata centerにある。
しかしconsumerは、physical rack一台ずつではなく、service interfaceからvirtual machine、storage、database、application等のresourceを要求する場合がある。
cloudは場所が消える魔法ではない。
physical resourceの見え方とcontrol boundaryを変えるmodelだ。
NIST定義には、五つのessential characteristicsがある。
on-demand self-service。
broad network access。
resource pooling。
rapid elasticity。
measured service。
一語ずつを便利さの広告として読まず、consumerが何を要求し、providerが何を制御し、何を観察できるかへ戻す。
on-demandは、考えなくてよいという意味ではない
on-demand self-serviceでは、consumerがprovider staffとの個別やり取りなしにresource capabilityをprovisionできる。
button、console、API、automation等のinterfaceがあり得る。
速く作れることと、正しいconfigurationであることは別だ。
resource type。
region / zone。
capacity。
network exposure。
identity / permission。
backup / retention。
budget / quota。
consumerが選ぶfieldはservice modelとproductで変わる。
defaultを押しただけで目的、security、availability、costが自動で最適になるとは決めない。
broad network accessも、誰にでもpublic accessさせる意味ではない。
standard mechanismでdifferent client platformから利用できるcharacteristicであり、authorizationやprivate connectivityは別に設計できる。
resource poolingは、rackを選ばないことと無限を分ける
providerはcompute、storage、memory、network bandwidth等のresourceをpoolし、demandに応じてconsumerへdynamically assign / reassignできる。
consumerは、exact physical resource locationを通常control / knowledgeしないlevel of location independenceを持つ。
一方で、country、state、region、data center等のhigher level locationを指定できる場合もある。
poolはinfiniteではない。
provider capacity、service quota、account limit、available instance type、regional failure等のboundaryがある。
「poolから出せる」と「今、要求した数を必ず即時に出せる」を同一視しない。
同じpoolに見えても、failure domainやdata residency requirementは別に確認する。
今回のfixture poolは、最大四workerまでをtest quotaとして持つ。
十二taskを十二physical serverへ固定するのではなく、available workerがqueueから一枚ずつ取る。
elasticityは、workerを増やすだけでは完成しない
rapid elasticityでは、capabilityをelasticにprovision / releaseし、需要に応じてoutward / inwardへscaleできる。
consumerからunlimitedに見える場合があっても、実際に無限という保証ではない。
何をsignalに増やすか。
どこまで増やすか。
何をsignalに減らすか。
provisioningに何秒かかるか。
quotaとbudgetを超えたらどうするか。
stateをどこへ置くか。
workerがduplicate taskを取ったとき、output identityをどう守るか。
workload designとpolicyが必要だ。
一台を大きくするscale upと、workerを増やすscale outは違う。
どちらが適切かはtask、state、software、limit、costで変わる。
cloudだから自動でscale outするとは限らない。
autoscalingを使っても、wrong signalやno capacityなら期待どおり動かない。
stateは、replaceable computeから外へ出す
すべてのcloud computeがephemeralとは限らない。
local diskがpersistentなserviceも、attached volumeを持つserviceもある。
だからこそservice contractを確認する。
今回のfixture workerはreplaceableで、local scratchはtask中だけ使うcontractだ。
source imageとcompleted outputは、persistent object shelfへ置く。
queueはpending task identityを持つ。
workerは一枚をclaimし、sourceを読み、outputをdeterministic keyへ書き、complete receiptを返す。
workerがreplaceされても、source、completed output、pending queueを失わない。
duplicate deliveryが起き得るsystemなら、idempotency、deduplication、conditional write等を別途設計する。
「storage serviceへ置いた」だけでbackup、retention、versioning、encryption、correct accessが完成するわけでもない。
state requirementを先に決め、service featureと照合する。
measured serviceは、usageを見える形にする
cloud systemはservice typeに合ったabstraction levelでresource useをmeterし、monitor、control、reportできる。
storage amount、processing、bandwidth、active account等が例になる。
measured serviceは、必ず安い、秒単位課金、使った分だけの一種類のpriceを意味しない。
subscription、reservation、minimum charge、data transfer、request count等、price modelはserviceごとに違う。
usage visibilityを、cost allocation、capacity planning、anomaly detection、release確認へ使う。
resourceを作れたことだけで終えず、不要になったresourceがreleaseされたかを見る。
idle resource、forgotten snapshot、public address、unused key等もlifecycleに入れる。
今回のfixtureはcurrencyを扱わず、worker tick、storage object、request countだけをusage ledgerへ残す。
SaaS / PaaS / IaaSで、選べるlayerが変わる
NIST SP 800-145はSoftware as a Service、Platform as a Service、Infrastructure as a Serviceの三service modelを示す。
SaaS consumerはprovider applicationを使う。
PaaS consumerはprovider-supported environmentへ自分のapplicationをdeployする。
IaaS consumerはprocessing、storage、network等をprovisionし、OSやapplicationをcontrolする範囲を持つ。
具体的なboundaryはservice contractへ戻る。
NIST SP 500-292 Cloud Computing Reference Architectureはphysical resource layerの上にresource abstraction / control layerとservice orchestrationを置き、provider / consumer間のcontrol scopeがservice modelで変わることを示す。
providerがphysical serverを管理するから、consumerの責任が0になるわけではない。
consumer data、identity、access、application configuration、guest OS、network rule等のどこを誰がcontrolするかはservice modelによって違う。
「cloudへ置いたから安全」「providerがbackupするはず」「複数facilityに自動配置されるはず」と推測しない。
service specification、configuration、evidenceを確認する。
イトの前に、三つの選択肢が開く
releaseまで、あと三十五秒。
A もっと大きいsingle workerへreplaceする
source、output、admin keyをlocal shelfへ置いた構造は変えない。
次のreplaceでもstateを失い、queueは一台ずつしか進まない。
B one-box imageを十二個copyする
computeは増える。
しかしbroad admin keyとlocal outputもduplicateし、task identityとusage limitを分けない。
C state、queue、worker、access、scale / release ruleを分ける
source / outputをpersistent object shelfへ置く。
queueへtwelve task identitiesを置き、replaceable worker templateにはone-task capabilityのlimited tokenだけを渡す。
queue depth、max worker quota、budget stop、drain後release、output identityを先に決める。
ピコはresource cardにもscale holderにも触れなかった。
「一台を借り直すんじゃない。残すものと、増減させるものを分けてpoolへ頼む」
イトはCを選んだ。
自分でone-box holderを閉じ、broad admin keyをworker templateから外した。
source / output shelf、queue、limited worker token、scale / release rule、usage ledgerを五つのholderへ分けた。
queueをdrainし、workerをreleaseした
イトはsource image twelveをpersistent shelfへ置いた。
queueへtask identity twelveを入れた。
fixture ruleはactive worker min 1 / max 4。
workerはone taskをclaimし、sourceを読み、deterministic output keyへwriteし、receiptを返す。
queue depthが増え、resource poolはquota内でworkerを4までprovisionした。
イトはsingle outputだけで成功と決めず、queue、output identity、permission、usageを一緒に見た。
completed outputは12。
persistent outputは12。
missingは0。
duplicate outputは0。
broad admin token copyは0。
max active workerは4。
queue drain後のactive workerは1。
measured usage recordは1。
budget stop breachは0。
scaleできたことを、無限の証明にしない
今回4 workerがprovisionできたのは、fixture quota、available capacity、worker template、queue ruleがそろっていたからだ。
次回も同じtimeで起動する保証ではない。
quota exhaustion、regional capacity、dependency failure、wrong permission、bad image、queue outage等でscaleできない場合がある。
fallback、backpressure、deadline、partial completion、retry / deduplicationをservice requirementへ戻す。
workerを1へ戻したこともoutcomeだ。
増やす動作だけをelasticityと呼ばず、需要が下がったとき安全にreleaseできるところまで観察する。
object shelfを残すretention期間、outputを削除するowner、tokenをrotateする条件もlifecycleに含める。
cloud consoleにresourceが見えなくても、billing / log / backup / replicaが残る場合がある。
deletion semanticsとretention policyを確認する。
貸しserverではなく、control contractを残す
workbenchには、十のevidenceが残った。
source object twelve。
task identity twelve。
completed output twelve。
missing zero。
duplicate zero。
broad admin token copy zero。
max worker four。
after-drain worker one。
usage record one。
budget breach zero。
cloudを「遠くにある誰かのserverを借りる仕組み」と判断しない。最初に必要なservice、persistent state、replaceable compute、network / access boundaryを分け、resource poolへdesired stateとして渡す。elasticityはpolicy・quota・capacity・workload designがそろって初めて働く。scale out後はqueue、output identity、permission、measured usage、releaseまで観察する。providerへ任せる範囲が増えても、利用者のdata・access・configuration判断は消えない。
「cloudで選ぶのはmachineだけじゃない。残すstate、渡す権限、増減の条件、終わったあとのreleaseまでだ」
イトはone-box holderをresource poolへ戻さず、五つのcontrol holderとtwelve output receiptsの外へ置いた。
最後のoutput cardへ、viewer requestが一枚届いた。
resource poolの奥で、web listener、application worker、object shelfの三つのresponse holderが同時に光る。
どれがHTTP responseを返すserverなのだろうか。
次回：web serverは、一台の返却係？
イトはviolet requestを、physical server card一枚へ直接貼ろうとした。
「HTMLを返すmachineが、web serverだよね」
ピコはserver cardへ触れず、listener、application、static object、response boundaryを照らした。
次回、ピコルート第62話。
イトは、web serverをHTMLを返す一台のserverだと決めなかった｜誰がresponseを作る？