การสร้างและการปฏิบัติการระบบจัดเก็บข้อมูลขนาดมหึมาที่ชื่อว่า S3
(allthingsdistributed.com)- Amazon S3 เริ่มต้นจาก object storage บนพื้นฐาน HTTP REST API ที่เปิดตัวเมื่อวันที่ 14 มีนาคม 2006 และเติบโตเป็นบริการขนาดใหญ่ที่มีทั้งไมโครเซอร์วิสนับร้อยและหลายทีมเฉพาะทางร่วมกันดูแล
- ขนาดของ S3 ไม่อาจอธิบายได้ด้วยโค้ดเพียงอย่างเดียว แต่เป็นระบบที่ ฮาร์ดดิสก์·เฟิร์มแวร์·ดาต้าเซ็นเตอร์·องค์กรปฏิบัติการ·เวิร์กโหลดของลูกค้า เชื่อมโยงและเปลี่ยนแปลงไปด้วยกันอย่างต่อเนื่อง
- แม้ HDD จะมีความจุและความคุ้มค่าด้านต้นทุนดีขึ้นมาก แต่ประสิทธิภาพการเข้าถึงแบบสุ่มยังติดอยู่กับข้อจำกัดทางกลไก ทำให้ S3 มอง การจัดการความร้อนของ I/O และการวางข้อมูลบนดิสก์นับล้านเป็นปัญหาหลัก
- การทำซ้ำข้อมูลและ erasure coding บนพื้นฐาน Reed-Solomon ไม่ได้ช่วยแค่เพิ่มความทนทาน แต่ยังช่วยเลี่ยงดิสก์ที่โอเวอร์โหลดและส่งคำขออ้อมไปยังจุดอื่น จึงมีส่วนช่วยด้านประสิทธิภาพและการควบคุม tail latency ด้วย
- การปฏิบัติการของ S3 ถูกออกแบบให้รักษาทั้งความเร็วในการพัฒนาและมาตรฐานความทนทานระดับสูง ผ่าน durability review, ShardStore ที่พัฒนาด้วย Rust, lightweight formal verification และ ownership ระดับทีม
มอง S3 เป็นระบบบริการขนาดมหึมาระบบเดียว
- S3 คือ บริการ object storage และประกอบด้วย HTTP REST API, front-end fleet, namespace service, storage fleet ที่ใช้ฮาร์ดดิสก์ และ background job fleet
- แต่ละองค์ประกอบขนาดใหญ่มีโดเมนแยกต่างหากภายในองค์กร S3 มีผู้นำและหลายทีมดูแล และองค์ประกอบย่อยด้านในก็ทำงานในลักษณะเดียวกันโดยมี fleet และทีมของตัวเอง
- ปัจจุบัน S3 ประกอบด้วย ไมโครเซอร์วิสนับร้อย และปฏิสัมพันธ์ระหว่างทีมก็ใกล้เคียงกับข้อตกลงระดับ API
- หากออกแบบความเป็นโมดูลไม่ดี ปฏิสัมพันธ์ระหว่างทีมก็อาจไม่มีประสิทธิภาพและดูไม่เป็นธรรมชาติ การแก้สิ่งนี้จึงเป็นส่วนหนึ่งของการออกแบบทั้งซอฟต์แวร์และทีมไปพร้อมกัน
ไม่ใช่แค่ซอฟต์แวร์ แต่ทั้งบริการต่างหากที่เป็นระบบ
- ลูกค้า S3 ไม่ได้ซื้อซอฟต์แวร์แบบแพ็กเกจ แต่ซื้อ ประสบการณ์ของบริการ และคาดหวังคุณภาพที่ต่อเนื่องและคาดการณ์ได้
- ขอบเขตของระบบ S3 ไม่ได้หยุดอยู่แค่โค้ด
- โค้ดที่รันใกล้กับดิสก์
- ช่างเทคนิคที่ติดตั้ง storage rack ใหม่ในดาต้าเซ็นเตอร์
- แอปพลิเคชันของลูกค้าที่ทำ performance tuning
- องค์กรด้านฮาร์ดแวร์ การเงิน และวิศวกรรม
- S3 จึงใกล้เคียงกับ ระบบมีชีวิต ที่ซอฟต์แวร์ ฮาร์ดแวร์ และผู้คนเติบโตและเปลี่ยนแปลงร่วมกันอยู่ตลอดเวลา
- แผนภาพสถาปัตยกรรมบนไวต์บอร์ดที่ดูเรียบง่ายมักซ่อนขนาดและรายละเอียดของบริการภายในแต่ละกล่องไว้ ทำให้ประเมินระบบจริงต่ำกว่าความเป็นจริง
ข้อจำกัดทางกายภาพของ HDD ที่ส่งผลต่อการออกแบบ S3
- S3 เป็นระบบขนาดใหญ่มากที่ใช้ ฮาร์ดดิสก์หลายล้านลูก และคุณสมบัติของ HDD คือหนึ่งในข้อจำกัดหลักที่อยู่ใจกลางการออกแบบ
- นับจาก IBM 350 disk storage unit ในปี 1956 HDD พัฒนามาไกลมาก
- HDD ที่กล่าวถึงว่ามีความจุสูงสุดในปัจจุบันคือ Western Digital Ultrastar DC HC670 26TB
- นับจาก RAMAC ความจุดีขึ้น 7.2 ล้านเท่า
- ขนาดทางกายภาพเล็กลง 5,000 เท่า
- ต้นทุนต่อไบต์เมื่อปรับตามเงินเฟ้อแล้วถูกลง 6 พันล้านเท่า
- แต่ seek time ดีขึ้นเพียง 150 เท่า และประสิทธิภาพการอ่าน/เขียนแบบสุ่มยังคงอยู่ที่ราว 120 งานต่อวินาที
- ค่าประสิทธิภาพนี้แทบไม่ต่างจากตอนที่ S3 เปิดตัวในปี 2006 และก็ไม่ได้ต่างมากจากสิบปีก่อนหน้านั้นด้วย
- เพราะ HDD เป็นอุปกรณ์เชิงกล จึงต้องรอเวลาที่แขนอ่านเขียนเคลื่อนที่และจานหมุน ทำให้ประสิทธิภาพการเข้าถึงแบบสุ่มไม่ดีขึ้นตามอัตราการเพิ่มขึ้นของความจุ
- roadmap ของอุตสาหกรรมชี้ไปสู่ HDD ขนาด 200TB ภายในอีก 10 ปีข้างหน้า ซึ่งในระดับนั้น หากสมมติว่าเข้าถึงข้อมูลทั้งหมดแบบสุ่มอย่างเท่าเทียม จะเท่ากับอนุญาตได้เพียง 1 I/O ต่อวินาทีต่อข้อมูลดิสก์ 2TB
- S3 ยังไม่ได้ใช้ไดรฟ์ 200TB แต่คาดว่าจะใช้ทั้งไดรฟ์ขนาดนั้นและทุกขนาดระหว่างทางก่อนถึงจุดนั้น
การจัดการความร้อน: การวางข้อมูลและประสิทธิภาพ
- ใน S3 คำว่า heat หมายถึงจำนวนคำขอที่เข้ามายังดิสก์ลูกใดลูกหนึ่งในช่วงเวลาหนึ่ง
- หากจัดการ heat ไม่ดี คำขอจะไปรวมที่ดิสก์บางลูกจนเกิด hotspot และทำให้ประสิทธิภาพโดยรวมของคำขอที่พึ่งพาดิสก์นั้นแย่ลง
- hotspot ไม่ได้ทำให้ระบบล่มทันที แต่จะสร้างคิวคำขอและทำให้ประสบการณ์ของลูกค้าแย่ลง
- คำขอที่ต้องรอดิสก์ที่ยุ่งอยู่จะล่าช้า
- ความล่าช้านี้จะถูกขยายขึ้นไปยังชั้นบนของ storage stack ผ่าน I/O ที่ต้องพึ่งพา เช่น metadata lookup หรือ erasure coding
- ทำให้เกิดความล่าช้าสูงในคำขอบางส่วน หรือที่เรียกว่า straggler
- hotspot ของ HDD แต่ละลูกนำไปสู่ tail latency และหากปล่อยไว้ก็จะกระทบต่อ latency ของคำขอทั้งหมด
- ตอนที่ข้อมูลถูกเขียน S3 ไม่รู้ล่วงหน้าว่าอนาคตจะมีการเข้าถึงเมื่อไรและอย่างไร ทำให้การตัดสินใจวางข้อมูลตั้งแต่จังหวะเขียนเป็นเรื่องยาก
- ในระบบขนาดเล็ก การคาดการณ์และจัดการ I/O heat ทำได้ยากมาก แต่เมื่อเป็นสเกลและความเป็น multi-tenant แบบ S3 จะมีคุณลักษณะอีกแบบหนึ่งเกิดขึ้น
- เวิร์กโหลดแต่ละตัวมักนิ่งอยู่เกือบตลอดเวลาแล้วพุ่งขึ้นสูงฉับพลัน แต่เมื่อรวมเวิร์กโหลดนับล้านเข้าด้วยกัน อุปสงค์รวมจะเรียบและคาดการณ์ได้มากขึ้น
- เมื่อเกินสเกลระดับหนึ่ง เวิร์กโหลดเดี่ยวหนึ่งตัวจะมีผลต่อ peak โดยรวมได้ยากมากหรือแทบเป็นไปไม่ได้
การทำซ้ำข้อมูลและ erasure coding ช่วยทั้งความทนทานและประสิทธิภาพ
- วิธีทำ redundancy ในระบบจัดเก็บข้อมูลไม่ได้มีไว้แค่ป้องกันข้อมูลจากความขัดข้องของฮาร์ดแวร์ แต่ยังช่วยเรื่อง การกระจาย heat ด้วย
- การทำซ้ำข้อมูลช่วยให้ทนต่อความขัดข้องของดิสก์ได้ด้วยการเก็บสำเนาไว้หลายดิสก์ และทำให้คำขออ่านสามารถประมวลผลจากสำเนาใดก็ได้
- การทำซ้ำข้อมูลมีต้นทุนสูงในแง่ความจุ แต่มีประสิทธิภาพในมุมของ read I/O
- S3 ใช้ erasure coding ด้วย เพื่อไม่ต้องจ่าย overhead ของการทำซ้ำข้อมูลกับทุกข้อมูลทั้งหมด
- วิธีตัวอย่างใช้ algorithm อย่าง Reed-Solomon
- แบ่งอ็อบเจ็กต์ออกเป็น identity shard จำนวน k ชิ้น
- สร้าง parity shard เพิ่มอีก m ชิ้น
- ถ้าใช้ shard ได้ k ชิ้นจากทั้งหมด k+m ชิ้น ก็สามารถอ่านอ็อบเจ็กต์ได้
- วิธีนี้ช่วยลด overhead ด้านความจุ ขณะที่ยังทนต่อความขัดข้องได้ในระดับเดียวกัน
กลยุทธ์การวางข้อมูลและการแยกเวิร์กโหลดของลูกค้า
- วิธีทำ redundancy จะแบ่งข้อมูลออกเป็นชิ้นมากกว่าจำนวนครั้งที่ต้องอ่านจริง ทำให้สามารถส่งคำขอโดยหลบดิสก์ที่โอเวอร์โหลดได้
- S3 ยังกระจายอ็อบเจ็กต์ใหม่ออกไปกว้างทั่วทั้ง disk fleet เพื่อลด heat ลงอีก
- อ็อบเจ็กต์แต่ละชิ้นอาจถูก encode คร่อมหลายสิบไดรฟ์ และอ็อบเจ็กต์ต่างกันก็จะถูกวางลงบนชุดไดรฟ์ที่ต่างกัน
- เมื่อกระจายอ็อบเจ็กต์ในแต่ละบัคเก็ตไปยังดิสก์จำนวนมาก จะเกิดข้อดีสองอย่าง
- สัดส่วนข้อมูลของลูกค้าในดิสก์ลูกใดลูกหนึ่งจะเล็กมาก ทำให้เวิร์กโหลดเดี่ยวสร้าง hotspot บนดิสก์เฉพาะลูกได้ยาก
- เวิร์กโหลดเดี่ยวสามารถ burst ได้ถึงระดับจำนวนดิสก์ที่หากสร้างเป็นระบบแยกเองจะทำได้ยากและมีต้นทุนสูง
- burst จากลูกค้าวิเคราะห์จีโนมที่รันการวิเคราะห์แบบขนานบน Lambda หลายพันฟังก์ชัน สามารถถูกประมวลผลได้ด้วย ดิสก์เดี่ยวมากกว่าหนึ่งล้านลูก
- ปัจจุบัน S3 มีลูกค้าหลายหมื่นรายที่มีบัคเก็ตกระจายอยู่บนไดรฟ์หลายล้านลูก
- จุดต่างของ S3 ไม่ได้อยู่แค่ขนาดของระบบจัดเก็บข้อมูลเอง แต่รวมถึงสเกลที่ลูกค้าและเวิร์กโหลดถูกรวมกันจนสามารถเปลี่ยนธรรมชาติของระบบได้ด้วย
Durability review และ guardrail
- Amazon ให้ความสำคัญกับการทำให้นักวิศวกรและทีมสามารถล้มเหลวได้อย่างรวดเร็วและปลอดภัย
- S3 ใช้กระบวนการ durability review เพื่อให้เคลื่อนที่ได้เร็ว ขณะเดียวกันก็ยังให้บริการ storage ที่มีความทนทานสูง
- durability review ไม่ใช่กลไกที่อยู่ในโมเดลเชิงสถิติ 11 9s โดยตรง แต่ถือว่าสำคัญในการปฏิบัติการ S3
- หากการเปลี่ยนแปลงของวิศวกรอาจส่งผลต่อสถานะความทนทาน ก็จะทำ durability review
- กระบวนการนี้ยืมแนวคิด threat model จากงานวิจัยด้านความปลอดภัย
- เขียนสรุปการเปลี่ยนแปลง
- สร้างรายการภัยคุกคามอย่างครอบคลุม
- สรุปว่าการเปลี่ยนแปลงนั้นต้านทานภัยคุกคามเหล่านั้นได้อย่างไร
- durability review มีบทบาทสองอย่าง
- ทำให้ผู้เขียนและผู้รีวิวคิดเชิงวิพากษ์เกี่ยวกับความเสี่ยงที่ต้องปกป้อง
- แยกความเสี่ยงออกจากมาตรการรับมือ เพื่อให้พูดคุยแต่ละเรื่องได้อย่างอิสระ
- เมื่อต้องหามาตรการรับมือ แนวทางที่นิยมคือใช้ guardrail ที่เรียบง่ายแต่ทรงพลังเพื่อป้องกันกลุ่มความเสี่ยงกว้าง ๆ แทนการเพิ่มมาตรการเฉพาะจุดให้แต่ละความเสี่ยงย่อย
ShardStore, Rust และ lightweight formal verification
- เมื่อหลายปีก่อน S3 เริ่มโครงการเขียนชั้นล่างสุดของ storage stack ขึ้นใหม่ทั้งหมดตั้งแต่ต้น นั่นคือส่วนที่จัดการข้อมูลบนดิสก์แต่ละลูกโดยตรง
- ชั้นจัดเก็บข้อมูลใหม่นี้มีชื่อว่า ShardStore
- หนึ่งใน guardrail ที่เลือกใช้ระหว่างสร้าง ShardStore ใหม่คือ lightweight formal verification
- ทีมย้ายภาษา implementation ไปเป็น Rust เพื่อหาบั๊กได้เร็วขึ้น
- ใช้ประโยชน์จาก type safety
- ใช้ประโยชน์จากการรองรับของภาษาอย่างเป็นระบบ
- เขียนไลบรารีเพื่อขยาย type safety ไปยังโครงสร้างข้อมูลบนดิสก์ด้วย
- ในมุมของการ verification ทีมเขียนโมเดลแบบลดความซับซ้อนของ logic ใน ShardStore ด้วย Rust และเก็บไว้ใน repository เดียวกับ implementation ของ ShardStore ที่ใช้จริงใน production
- โมเดลนี้ทำหน้าที่เป็น ข้อกำหนดที่รันได้จริง โดยตัดความซับซ้อนของชั้นจัดเก็บข้อมูลบนดิสก์จริงและของ HDD ออกไป
- แม้ขนาดของโมเดลจะมีเพียงประมาณ 1% ของระบบจริง แต่ก็ทำให้สามารถทดสอบในระดับที่ไม่สมจริงเมื่อเทียบกับฮาร์ดไดรฟ์ 120 IOPS ได้
- งานนี้ยังถูกเผยแพร่เป็นบทความ SOSP ชื่อ Using lightweight formal methods to validate a key-value storage node in Amazon S3
- หลังจากนั้นยังใช้เครื่องมือและเทคนิคเดิมอย่าง property-based testing เพื่อตรวจสอบว่าพฤติกรรมของ implementation สอดคล้องกับข้อกำหนดหรือไม่
- แก่นสำคัญคือการนำเทคนิคจากงานวิจัยด้าน formal verification มาทำให้เป็น ระบบใช้งานจริงในอุตสาหกรรม ในรูปของโค้ดที่วิศวกรทั่วไปดูแลได้ และเครื่องมือที่รันกับทุก commit
- guardrail ด้าน verification ช่วยเพิ่มความมั่นใจให้ทีมพัฒนาได้เร็วขึ้น และยังคงใช้ต่อเนื่องแม้จะมีวิศวกรใหม่เข้าร่วมทีมแล้วก็ตาม
รับมือปัญหาการขยายของทีมและบุคคลด้วย ownership
- ที่ Amazon คำว่า ownership คือแนวคิดที่ต้องระบุให้ชัดว่ามีบุคคลหรือทีมเดียวใดรับผิดชอบจนสำเร็จสำหรับงานหรือบริการหนึ่ง ๆ
- ใน S3 หากต้องการเคลื่อนที่เร็วพร้อมรักษามาตรฐานคุณภาพระดับสูง ทีมจำเป็นต้องเป็นเจ้าของสิ่งที่ดูแล
- เป็นเจ้าของข้อตกลง API กับระบบอื่น
- รับผิดชอบด้านความทนทาน ประสิทธิภาพ และความพร้อมใช้งาน
- หากบั๊กที่ไม่คาดคิดกระทบต่อความพร้อมใช้งาน ก็ต้องลุกมาแก้แม้ตอนตี 3
- หลังแก้บั๊กแล้วก็ต้องปรับปรุงระบบเพื่อไม่ให้เกิดซ้ำอีก
- ownership มาพร้อมความรับผิดชอบสูง และก็ต้องมีความไว้วางใจควบคู่กัน
- หากบุคคลหรือทีมจะเป็นเจ้าของบริการจริง ก็ต้องมีพื้นที่ให้ตัดสินใจเองได้ว่าจะส่งมอบอย่างไร
- แม้แต่ในประสบการณ์โครงการวิจัยระดับบัณฑิตศึกษา นักศึกษาก็มักทุ่มเทลึกขึ้นเมื่อรู้สึกว่านี่คือไอเดียของตนและสามารถพัฒนาต่อเองได้
- ในบทบาทวิศวกรอาวุโสมาก ๆ วิธีที่มีประสิทธิภาพกว่าการยื่นคำตอบให้ทีมไป deploy ตรง ๆ คือการนิยามปัญหาให้ดี และช่วยให้ทีมเป็นเจ้าของวิธีแก้
- ในปัญหาที่มีทางออกได้หลายแบบ การทำให้มีการเลือกทางออกที่เหมาะสมก็คือวิธีหนึ่งในการมอบ ownership ของวิธีแก้ ให้กับใครบางคน
ข้อสรุปจาก S3
- สเกลทางเทคนิคของ S3 ไม่ได้เป็นแค่เวอร์ชันที่ใหญ่ขึ้นของระบบเล็ก แต่แตกต่างกันโดยพื้นฐานทั้งในแง่เวิร์กโหลด โครงสร้าง และวิธีปฏิบัติการ
- “ระบบ” ไม่ได้หมายถึงแค่ซอฟต์แวร์ แต่รวมถึงการปฏิบัติการของบริการ องค์กรปฏิบัติการ และโค้ดของลูกค้าที่ทำงานร่วมกับบริการนั้นด้วย
- เพราะองค์กรเองก็เป็นส่วนหนึ่งของระบบ มันจึงมีทั้งปัญหาการขยายตัวของตัวเองและโอกาสในการนวัตกรรมของตัวเอง
- หากต้องการประสบความสำเร็จในบทบาทส่วนบุคคล ควรโฟกัสที่การอธิบายปัญหาให้ชัด มากกว่าการยื่นคำตอบ และสนับสนุนให้ทีมวิศวกรรมที่แข็งแกร่งเป็นเจ้าของวิธีแก้จริง ๆ
2 ความคิดเห็น
ความคิดเห็นจาก Hacker News
หนึ่งในบทสนทนาที่จำได้ตอนอยู่ AWS คือ แม้แต่ เหตุการณ์หนึ่งในพันล้าน ก็เกิดขึ้นทุกวันในสเกลของ S3
เรื่องที่ปกติเราจะมองข้ามเพราะโอกาสเกิดน้อยเกินไปจนไม่คุ้มกังวล ก็จำเป็นต้องพิจารณาและจัดการให้ได้
ดีใจที่ได้เห็นแนวทางอย่าง ShardStore โดยเฉพาะ formal verification และการทดสอบแบบอิงคุณสมบัติ บริการรุ่นก่อน ๆ มีบั๊กเยอะพอจะชี้ให้เห็นความเสี่ยงของการเติบโตแบบค่อยเป็นค่อยไปได้ชัดเจน แต่อย่างน้อยก็ถูกออกแบบให้ล้มเหลวได้อย่าง “ปลอดภัย” เพื่อป้องกันการสูญหายของข้อมูล และวิศวกร S3 ก็หมกมุ่นกับเรื่องนั้นมาก
และไม่ได้มีแค่ S3 ด้วย เช่น ใน Prime Day 2022 แค่ workload ของ Amazon อย่างเดียว DynamoDB ก็พุ่งไปถึงมากกว่า 105 ล้านครั้งต่อวินาที: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
ในบทความ Andy ยังพูดถึงเทคนิค formal แบบเบา ๆ และการนำ Rust มาใช้ในทีมด้วย ในสเกลที่แม้แต่เหตุการณ์ความน่าจะเป็นต่ำมากก็กลายเป็นเรื่องปกติ จำเป็นต้องลงทุนกับเครื่องมือและกระบวนการหลายชั้นเพื่อความถูกต้อง
เลยอธิบายว่าถ้าไต่ไปถึงเป้าหมาย 500k TPS มันคือ 30 ครั้งต่อนาที แล้วถามว่า “สัปดาห์นั้นอยากเข้าเวร on-call ไหม?” ใน stack แบบนั้น “การยึดมาตรฐานสูงสุด” มีความหมายต่างจากองค์กรส่วนใหญ่โดยสิ้นเชิง
โชคดีที่อัลกอริทึมดี และฮาร์ดแวร์สมัยนี้ก็เสถียรกว่ามากด้วย
ในหัวก็มีเสียงเอียง ๆ นิดหน่อยที่พร้อมถือป๊อปคอร์นดูผลกระทบ ถ้าโชคดีได้เห็นการชนกันครั้งใหญ่ครั้งแรกของ cryptographic hash
ทำงานด้านจีโนมิกส์และได้ดูแลที่เก็บข้อมูลระดับเพตะไบต์มามากมายตลอด 10 ปีที่ผ่านมา
หลังจากใช้ AWS S3, GCP GCS และระบบจัดเก็บข้อมูลสำหรับฮาร์ดแวร์แบบ colocation (Ceph, Gluster และระบบของ HP ที่ลบชื่อออกจากความทรงจำไปแล้ว) ก็ยิ่งเคารพความพยายามที่ต้องใช้ในการปฏิบัติการระบบแบบนี้มาก
ประโยชน์ของการแชร์ disk I/O กับลูกค้าจำนวนมหาศาลรายอื่น ๆ ก็ประเมินค่าต่ำไปได้ยาก คำว่า “heat” ที่บทความใช้เพิ่งเคยได้ยินครั้งแรก แต่ในระบบเดี่ยว ๆ การบรรเทาเรื่องนี้ทำได้ยากจริง ๆ ในคลัสเตอร์ colocation ของเรา เราต้องแก้ระบบ batch ให้มอง I/O เป็นทรัพยากรที่จัดสรรได้เหมือน RAM หรือ CPU เพื่อจัดการ I/O ระหว่างงานขนาดใหญ่ให้เหมาะสม S3 และ GCP แพงมากก็จริง แต่บางครั้งประสิทธิภาพก็คุ้มราคานั้น
บทความแบบนี้แหละที่ผมคิดว่าเป็นด้านที่ดีที่สุดของ HN
จากมุมมองของ cloud storage ลูกค้าที่ดีที่สุดคือลูกค้าที่เก็บข้อมูลมหาศาลแต่แทบไม่อ่านเลย คล้ายกับการเช่าฮาร์ดดิสก์ แต่ถ้าเติมแต่ละดิสก์บางส่วนด้วยข้อมูล “เย็น” ก็ยังสามารถใช้ความจุ I/O ทั้งหมดของดิสก์เดียวกันเพื่อจัดการงานร้อนต่อไปได้
ถ้าสมดุลอย่างระมัดระวังมากว่าจะวางข้อมูลใดไว้บนไดรฟ์ไหน ก็ยังใช้ไดรฟ์ทั้งหมดต่อไปได้ แม้ข้อมูลส่วนใหญ่จะไม่ถูกใช้งาน ดังนั้นการเก็บจึงค่อนข้างถูก ส่วนการอ่านค่อนข้างแพง
แม้จะรองรับ S3 ประสิทธิภาพก็มักช้ากว่าระดับที่ควรทำได้มาก
มันยาก และต้องขอโทษที่ read availability อยู่แค่ราว 99.95%
ถ้า S3 ระบุ โปรโตคอลเรียบง่ายบน OAuth2 สำหรับมอบสิทธิ์การอ่าน/เขียน ก็น่าจะมีหลายอย่างที่สร้างขึ้นมาได้
โลกนี้ต้องการโปรโตคอลบน HTTP ที่ให้แอปเข้าถึงข้อมูลแทนผู้ใช้ได้ Google Drive ใกล้เคียงที่สุดในเรื่องนี้ แต่มีผู้ให้บริการรายเดียว และยังมีปัญหาอื่น ๆ ด้วย[0] น่าเสียดายที่ remoteStorage ไม่สามารถตั้งหลักได้ หวังว่า Solid จะไปได้ดี แต่สำหรับผมมันรู้สึกซับซ้อนเกินไป แนวทางของผมต่อปัญหานี้คือ https://gemdrive.io/ แต่ตอนนี้แทบหยุดนิ่งอยู่ เพราะกำลังโฟกัสกับส่วนอื่นของสแต็กเซลฟ์โฮสต์
[0]: https://gdrivemusic.com/help
ถ้าจะทำให้ถูกต้องตอนนี้ยากมาก ผมถึงกับสร้างแอป CLI ทั้งตัวเพื่อแก้ปัญหา “ออกข้อมูลรับรอง AWS ที่เข้าถึงได้เฉพาะบัคเก็ตนี้เท่านั้น” แต่ก็ไม่อยากบอกให้ผู้ใช้ติดตั้งและรันอะไรแบบนี้: https://s3-credentials.readthedocs.io/en/stable/
ในทางปฏิบัติ ถ้ามีไลบรารีที่มี dependency ฝั่งไคลเอนต์ให้น้อยที่สุด ซึ่งเมานต์ไดเรกทอรีโลคัลที่จริง ๆ แล้วคือบัคเก็ต S3 ของผู้ใช้ได้ ก็คงดี
เพราะคู่แข่งสามารถบุกเข้ามาด้วย การทำงานร่วมกันเชิงปรปักษ์ ได้ทุกเมื่อ
น่าเสียดายมากที่โครงการทั้งหมดที่เคยพยายามสร้าง หรือกำลังสร้างอธิปไตยเหนือข้อมูลของผู้ใช้ ต่างไหลไปทางคริปโตแปลก ๆ กันหมด
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
แก้ไข: ดูเหมือนผมอ่านคอมเมนต์ผิดไป เข้าใจว่าแอปต้องการมอบสิทธิ์ข้อมูลผู้ใช้ให้ไคลเอนต์ แต่จริง ๆ แล้วน่าจะเป็นผู้ใช้ต้องการมอบสิทธิ์ข้อมูลของตนให้แอป เป็นคนละ use case กัน
สเปกของ IBM RAMAC ระบุว่า ความจุ 3.75MB, ประมาณ 9,200 ดอลลาร์ต่อเทราไบต์ ซึ่งไม่น่าจะถูกต้องได้
ถ้าเอาต้นทุนคูณกับความจุ ราคาของไดรฟ์จะเหลือ 3 เซนต์
เว็บไซต์นี้[1] บอกว่า “เก็บข้อมูลได้ประมาณ 2,000 บิตต่อตารางนิ้ว และราคาซื้ออยู่ที่ประมาณ 10,000 ดอลลาร์ต่อเมกะไบต์”
ดังนั้นสเปกน่าจะเป็น 9,200 ดอลลาร์ต่อเมกะไบต์มากกว่า ถ้าอย่างนั้นราคาไดรฟ์จะเป็น 34,500 ดอลลาร์ ซึ่งดูสมเหตุสมผลกว่า
[1]: https://www.historyofinformation.com/detail.php?entryid=952
มันมี 30 ล้านบิต และเป็นตัวเลขที่นับเฉพาะบิตข้อมูล 6 บิตโดยไม่รวมพาริตี แต่เพราะให้เช่าเดือนละ 3,000 ดอลลาร์ จึงไม่มีต้นทุนคงที่แบบเดียวกับการซื้อไดรฟ์จริงเป็นเงินก้อน ในแง่นั้นก็คล้ายกับโมเดลของ S3 อยู่พอสมควร
สิ่งที่คนส่วนใหญ่ไม่ตระหนักคือ ความมหัศจรรย์ไม่ได้อยู่ที่การจัดการตัวระบบเอง แต่อยู่ที่ การทำให้การอนุญาตสิทธิ์ดูเหมือนไม่มีต้นทุน
ในระบบกระจาย การอนุญาตสิทธิ์เป็นเรื่องยากมหาศาล ในสเกลของ AWS แทบจะเหมือนเวทมนตร์ AWS มีโมเดลสิทธิ์ที่ละเอียด และการเปลี่ยนแปลงสิทธิ์ก็น่าจะแพร่กระจายไปทั่วโครงสร้างพื้นฐานด้วยความเร็วระดับต่ำกว่ามิลลิวินาที ทั้งที่กำลังประมวลผลคำขอเป็นล้านล้านรายการ
ส่วนนี้กับการบันทึกล็อก/การกระทบยอดสำหรับการคิดเงิน คือสององค์ประกอบแบบเวทมนตร์ของ AWS ที่ผมอยากอ่านเป็นบทความ
S3 จัดการการควบคุมการเข้าถึงต่างจากบริการอื่น โดยสิทธิ์จะผูกอยู่กับทรัพยากรเอง น่าจะเป็นเพราะเรื่องความเร็ว
หนึ่งในเหตุผลที่แนวทาง bucket/key มีความพิเศษ คือเมื่อ IAM ออกมา โมเดลนี้ก็ใช้งานกันอยู่แล้ว
ที่ยังคงรักษาไว้หลังจากนั้น น่าจะเป็นเพราะการเอาโมเดลเดิมออกเป็นงานยาก และอาจทำให้การตั้งค่าของลูกค้าจำนวนมากพังได้
“ในฐานะวิศวกรที่อาวุโสมากในบริษัท แน่นอนว่าผมมีความเห็นที่หนักแน่นและมีวาระทางเทคนิคอยู่แล้ว แต่เวลาโต้ตอบกับวิศวกร ถ้าแค่พยายามแจกไอเดียให้ ทุกคนก็ประสบความสำเร็จได้ยาก ไอเดียที่ตัวเองไม่ได้เป็นเจ้าของนั้นทุ่มเทให้ได้ยากกว่ามาก ดังนั้นเวลาทำงานกับทีม ผมจึงใช้กลยุทธ์ให้ไอเดียที่ดีที่สุดของผมกลายเป็นไอเดียที่คนอื่นเสนอ ไม่ใช่ผมเสนอเอง ผมตั้งใจใช้เวลากับการพัฒนาและอธิบายปัญหาให้ออกมาดีมาก ๆ มากกว่าการขายวิธีแก้ปัญหา วิธีแก้ปัญหามักมีได้หลายทาง และการเลือกทางที่ถูกต้องคือการทำให้ใครสักคนเป็นเจ้าของวิธีแก้นั้น”
“ผมได้เรียนรู้ว่า ถ้าจะประสบความสำเร็จจริง ๆ ในบทบาทของผม ต้องโฟกัสกับการอธิบายปัญหาให้ชัดเจน ไม่ใช่วิธีแก้ และต้องหาวิธีสนับสนุนให้ทีมวิศวกรที่แข็งแกร่งได้เป็นเจ้าของวิธีแก้นั้นอย่างแท้จริง”
ชอบส่วนนี้มาก ทำให้นึกถึง Ikea effect อยู่พอสมควร ถ้าอยากให้ใครมีแพสชันกับงานที่ทำ ต้องส่งเสริมความรู้สึกเป็นเจ้าของ และวิธีที่ดีก็คือทำให้งานนั้นกลายเป็น “ไอเดียของคนนั้น”
สุดท้ายแล้ว ผู้คนมักมองต่างกันตั้งแต่แรกว่า “ปัญหา” คืออะไร
โชคดีที่ไม่ใช่ทุกปัญหาเป็นแบบนี้ แต่ถ้าดูการถกเถียงเรื่อง “ปัญหาแพ็กเกจจิง” ของ Python ตัวอย่างเช่น จริง ๆ แล้วมีปัญหาต่างกันราว 6 เรื่องที่ผู้คนอธิบายกันคนละแบบอย่างมาก และปรากฏการณ์นี้ก็แสดงออกมาในทางที่ค่อนข้างแย่
ถ้า Andy Warfield อ่านอยู่ ซึ่งก็น่าจะอ่านอยู่ ผมมีคำถามว่า ตอนพัฒนาปัญหา การร่างแนวทางแก้ที่เป็นไปได้มีคุณค่าแค่ไหน? ถ้าอธิบายปัญหาได้ชัดเจน ก็คงมีแนวทางแก้ที่เป็นไปได้บางอย่างผุดขึ้นมาเอง แล้วมันคุ้มไหมที่จะแชร์แนวทางเหล่านั้นเพื่อให้เจ้าของที่เป็นไปได้เริ่มคิด? หรือดีกว่าที่จะโฟกัสเฉพาะปัญหา แล้วปล่อยพื้นที่ของวิธีแก้ให้เปิดกว้างทั้งหมด?
เพิ่มเติม มีแหล่งให้อ่านต่อเกี่ยวกับรูปแบบการทำงานของ individual contributor ที่อาวุโสมาก ๆ แบบนี้ไหม?
สำหรับผม มันฟังเหมือนกำลังพูดว่า “ไอ้ไพร่! ฉันไม่มีเวลามาสนใจปัญหาของแกหรอก ถ้าแกเอามาแต่ปัญหา ฉันก็ใช้ผลงานของแกเลื่อนตำแหน่งไม่ได้สิ”
ก่อนจะแก้ปัญหาได้ เราต้องเข้าใจปัญหานั้นและยอมรับว่ามันมีอยู่ก่อน
ในสถานการณ์ที่ไม่มีอำนาจหรือความเชี่ยวชาญที่ได้รับการยอมรับล่วงหน้า ซึ่งก็คือบริบทที่ปัญหาส่วนใหญ่ในชีวิตประจำวันปรากฏขึ้นนั้น ถ้าคุณผูกขาดช่องทางสนทนาสองทางด้วยการอธิบายปัญหาอย่างยาว ละเอียด และระมัดระวัง ก็อาจดูเหมือนคนที่พูดอย่างเดียวแต่ไม่ทำงาน หรือเหมือนคนที่ไม่อยากหาวิธีแก้ร่วมกับคนอื่นได้ง่าย
ดีใจที่ได้เห็นพนักงาน Amazon สามารถพูดถึงการทำงานภายในของ S3 ต่อสาธารณะได้
อยากได้ยินเพิ่มเติมว่า Glacier ทำงานอย่างไรด้วย เท่าที่ผมรู้ พวกเขาไม่เคยเปิดเผยว่าสื่อจัดเก็บข้อมูลพื้นฐานคืออะไร จึงมีการเดากันสารพัดว่าเป็นเทป, HDD แบบออฟไลน์ หรือ HDD แบบคัสตอม
แต่ก็มีคนที่ไม่เห็นด้วยอยู่เช่นกัน ยังเป็นปริศนาอยู่
อยากให้ AWS เล่าทุกอย่างเกี่ยวกับมันและเส้นทางทั้งหมดของมันให้ฟัง เป็นเรื่องที่น่าสนใจจริง ๆ
แค่วิศวกรคนหนึ่งเมาแล้วปากพล่อยก็พอแล้วแท้ ๆ ในสาขาที่สำคัญกว่านี้มาก ทหารคนหนึ่งในแมสซาชูเซตส์ปล่อยข้อมูลความมั่นคงแห่งชาติลง Discord เพื่อให้ดูเท่ต่อหน้าเพื่อนเกมเมอร์ และกำลังจะเจอโทษจำคุกยาว ผมนึกว่ารายละเอียดของ Glacier คงออกมาแล้วภายในตอนนี้
“ลองจินตนาการถึงหัวอ่านฮาร์ดดิสก์เป็นเครื่องบิน 747 ที่บินเหนือสนามหญ้าด้วยความเร็ว 75 ไมล์ต่อชั่วโมง ช่องว่างอากาศระหว่างพื้นเครื่องบินกับปลายหญ้ามีความหนาเท่ากระดาษสองแผ่น ถ้าวัดบิตบนดิสก์เป็นใบหญ้า ความกว้างของแทร็กจะกว้างเท่าใบหญ้า 4.6 ใบ และความยาวของบิตเท่ากับใบหญ้าหนึ่งใบ เมื่อเครื่องบินบินเหนือสนามหญ้าและนับใบหญ้า มันจะพลาดใบหญ้าเพียงหนึ่งใบทุก ๆ การบินรอบโลก 25,000 รอบ”
พอเห็นส่วนการกระจายโหลด ทำให้นึกถึงยุค KeyMap ของ S3 และช่วงที่พยายามย้ายจากการใช้งานรุ่นแรกไปสู่สิ่งนั้น
สิ่งที่ได้เรียนรู้คือ แม้จะระบุออบเจ็กต์/พาร์ทิชัน/บัคเก็ตที่ร้อนที่สุดได้แล้ว ก็ไม่สามารถแค่ย้ายแล้วจบได้ ต้องเรียงลำดับทุกอย่างก่อน วิธีแก้จริง ๆ คือเรียงลำดับ จากนั้นแบ่งโหลดพาร์ทิชันของโฮสต์เป็นควอร์ไทล์ แล้วค่อยย้ายพาร์ทิชันควอร์ไทล์ที่สองไปยังโฮสต์ที่มีโหลดต่ำที่สุด
ถ้าพยายามย้ายบัคเก็ตที่ร้อนที่สุด หรือควอร์ไทล์แรก สมาชิกที่เหลือจะรับโหลดเพิ่มขึ้นและล้มเหลวต่อเนื่อง
ผลข้างเคียงอีกอย่างคืออัตราข้อผิดพลาดเปลี่ยนจากคงที่ราว 1% ไปเป็นไม่มีข้อผิดพลาดอยู่หลายวัน และผลก็คือเราอัปเดตเกณฑ์แจ้งเตือนให้เข้มงวดขึ้นมาก เรื่องนี้น่าจะประมาณปี 2009
ผมเองก็มีพื้นหลังสายวิชาการจาก UM แต่แทนที่จะเรียนปริญญาเอก ผมเข้าร่วม S3 แทน แถมคล้องจองกันด้วย
S3 เป็นมากกว่าที่เก็บข้อมูล มันคือ มาตรฐาน
ชอบที่ในหลาย ๆ ที่สามารถใช้ที่เก็บข้อมูลที่เข้ากันได้กับ S3 ได้ โดยมักจะมีเงื่อนไขเล็กน้อยประกอบ ไม่รู้ว่ามาตรฐานนี้เปิดแค่ไหน หรือถ้าจะพูดว่า “S3 compatible” ต้องจ่ายเงินให้ Amazon หรือไม่ แต่มันเจ๋งดี
ตัวอย่างเช่น iDrive E2, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage, Backblaze B2
แก้ไข: ลองค้นดูแล้ว เหมือนว่า Azure จะไม่มีจริง ๆ :-/
ความคิดเห็นใน Hacker News
ทำงานในสายจีโนมิกส์และตลอด 10 ปีที่ผ่านมาได้จัดการระบบจัดเก็บข้อมูลระดับเพตะไบต์จำนวนมาก
ถ้า S3 ใช้โปรโตคอลที่อิง OAuth2 เพื่อมอบหมายสิทธิ์การเข้าถึงแบบอ่าน/เขียนได้ สิ่งที่เราจะสร้างได้คงมีอีกมาก
การจัดการการยืนยันตัวตนในระบบกระจายนั้นยากมาก
เป็นเรื่องดีที่ได้เห็นพนักงาน Amazon พูดคุยอย่างเปิดเผยเกี่ยวกับการทำงานภายในของ S3
ส่วนที่อธิบายโดยเปรียบเทียบหัวอ่านฮาร์ดไดรฟ์กับเครื่องบิน 747
ย้อนกลับไปสมัย S3 KeyMap ได้เรียนรู้ว่าแม้จะระบุ object/partition/bucket ที่ร้อนที่สุดได้แล้ว ก็ไม่ได้แปลว่าจะย้ายมันแล้วแก้ปัญหาได้ง่าย ๆ
S3 ไม่ใช่แค่ที่เก็บข้อมูลธรรมดา แต่เป็นมาตรฐาน