เห็นคำว่า Graviton นี่เราไม่ได้หมายถึงแรงโน้มถ่วงควอนตัมแต่อย่างใด แต่เรากำลังพูดถึง AWS Graviton กันอยู่ ซึ่งถ้าเอาแบบง่ายๆ AWS Graviton ก็คือ CPU Arm-based processors ของทาง AWS ซึ่งเป็นหนึ่งใน AWS custom chips ที่มีจุดเด่นในด้านของราคาต่อประสิทธิภาพ

ปัจจุบันเวอร์ชั่นล่าสุดของ AWS Graviton คือ Generation 4 ที่เพิ่งเปิดตัวกันไปในงาน AWS re:Invent 2023 ที่ผ่านมา (ขณะนี้อยู่ใน preview สามารถ signup เผื่อทดลองใช้งานได้) ซึ่งมีการปรับปรุงในเรื่องของ performance และ cost-effective ที่มากขึ้น

ประสิทธิภาพของ Graviton

ถ้าถามว่า อะไรที่ทำให้ AWS Graviton แรงกว่า คุ้มกว่า เรามาลองดูรูปนี้กันครับ

จากรูปนี้เราจะเห็นอยู่สองเรื่องนั่นก็คือ

1. Every vCPU is a full core - หมายความว่าโดยปกติแล้ว vCPU ที่เราเห็นๆกันมันเป็นแค่ thread (logical core) ไม่ใช่ physical core ซึ่งจริงๆแล้วเป็นการทำสิ่งที่เรียกว่า Simultaneous Multithreading หรือ hyperthreading ฉะนั้นเวลาที่ต้องประมวลผล workload จำนวนมาก อาจทำให้เกิด latency ขึ้นระหว่าง logical core ด้วยกันเองได้ (Core and Thread)

2. Uniform memory access - คือการที่ processor มี local memory เป็นของตัวเอง ไม่แชร์ข้ามระหว่างกัน ทำให้สามารถ access ได้ไวกว่า non-local memory (Memory Design NUMA)

ถ้าหากว่าใครไหวเรื่องพวกนี้แนะนำให้ไปต่อกับ AWS whitepaper อันนี้ได้เลยครับ
ส่วนตัวผมนั้น ไม่ไหวครับ 🥲

ด้วยสองเหตุผลที่กล่าวไปทำให้เราสามารถรีดประสิทธิภาพของ CPU ได้มากขึ้น แทบจะ 100% กันเลยทีเดียว ต่างจาก x86 ที่จะเริ่มมี Latency มากขึ้นเรื่อยๆเพราะ Physical core ถูกแบ่งกันใช้งาน ทำให้เราต้องมาตั้ง trigger scaling ตั้งแต่เนิ่นๆก่อนที่จะเกิด Bottleneck กันอย่างในปัจุบัน

ถัดไปลองมาดู Benchmark กันบ้างครับ

รูปนี้เป็น Benchmark ของทาง Anandtech ที่ทำเทียบระหว่าง AWS Graviton 2 กับ x86 ทั้งทางฝั่ง AMD และ Intel ครับ จะเห็นได้ว่าในจำนวนเงิน dollar ที่จ่ายไปเท่ากันนั้น การใช้งาน AWS Graviton สามารถให้ผลลัพธ์ที่ค่อนข้างมากกว่านั่นเอง และหากมาลองดู real world scenario ที่เราใช้กันอย่างเช่น Nginx ก็ยังให้ Requests/Sec ที่มากกว่าเช่นกัน

ลองมาดู feedback จากลูกค้าที่ใช้ AWS Graviton กันบ้างครับ

“AWS Graviton4 instances are the fastest EC2 instances we’ve evert tested and are delivering outstanding performance across our most competitive and latency sensitive workloads. we look forward to using Graviton4 to improve player experience and expand what is possible within Fortnite.”

Epic Game

“Integrating Graviton4-based instances into our environment was seamless and gave us an immediate performance boost out of the box, and we’re looking forward to using Graviton4 when it becomes generally available”

Datadog

“Measured up to 50% query performance improvement and 10%-15% reduced error rate (fewer timeouts)”

Stripe

อันนี้ก็เป็นแค่ตัวอย่างที่เราหยิบยกมาเบื้องต้นแค่นั้น จะเห็นได้ว่าหลายๆบริษัทสามารถนำ AWS Graviton มาใช้เพื่อเพิ่มประสิทธิภาพของระบบได้มากขึ้นเลยทีเดียว ถ้าหากว่าอยากอ่านเพิ่มเติม สามารถเข้าไปดูลูกค้าของ AWS Graviton เต็มๆได้ที่นี่เลยครับ

การใช้งาน Graviton

เกริ่นกันมาซะขนาดนี้ คิดว่าทุกคนคงอยากจะกระโดดเข้ามาใช้งานเจ้า CPU ตัวนี้ของ AWS กันเป็นแน่แท้ งั้นไม่รอช้าครับ เรามาดูกันดีกว่าว่าก่อนที่เราจะใช้งานเจ้า Graviton นี้ได้ เราต้องเตรียมความพร้อมอะไรกันบ้าง

1/ CPU Architecture

เนื่องด้วยความต่างของ CPU Architecture ทำให้เราต้องมีการเตรียมความพร้อมสำหรับการนำ software ไปรันอยู่บน AWS Graviton กันก่อนครับ สามารถเช็คไปทีล่ะข้อได้เลยตามรายการด้านล่างนี้ได้เลยครับ

• Language - ถ้าหากว่าภาษา programming ที่คุณใช้เป็นประเภทที่ต้อง compile ก่อน เช่น C, C++, GO, หรือ Rust ก็สามารถเปลี่ยนมา compile สำหรับ ARM64 Architecture ได้เลยครับ หรือถ้าภาษาที่ใช้เป็น Interpreted หรือ Compiled-bytecode เช่น Python, Java, PHP, Node.js หรือ .NET ก็แค่เปลี่ยนตัว runtime ให้เป็นของ ARM64 ก็เป็นอันเรียบร้อย จริงๆตอนที่เราทำเองอาจจะไม่ได้ง่ายขนาดนั้น ลองเข้าไปอ่านคำแนะนำเบื้องต้นของแต่ล่ะภาษาที่เราใช้งานกันได้เลยครับ
  • C/C++
  • Go
  • Java
  • .NET
  • PHP
  • Python
  • Rust

และเพื่อความมั่นใจก็ลองไปเช็ค Known issues กันก่อนซักเล็กน้อยเผื่อจะได้ไม่เสียเวลาไปกับปัญหาที่เราอาจจะเจอครับ

• Operating System - ปัจจุบันแทบจะทุก Linux distributions รองรับ ARM64 กันเป็นที่เรียบร้อย ถ้าหากคุณใช้ AMI มาตราฐานอย่าง Amazon Linux, Ubuntu, หรือ Alpine Linux ก็สบายใจได้ แต่ถ้าไม่หรือเป็นมีการปรับแต่งกันขึ้นมาเอง ก็อาจจะต้องไปดู Operating System ที่รองรับกันนิดนึงว่ารองรับหรือไม่ครับ

• Version - นอกจากการเปลี่ยนวิธีการ compile ของภาษาที่เราใช้แล้ว เราก็ควรจะอัพเกรดเวอร์ชั่นที่ใช้ให้ใหม่ที่สุดเท่าที่จะเป็นไปได้ด้วยเช่นกัน เพราะในตอนที่ยุคของ ARM computer มาถึง หลายๆภาษาก็เริ่มมีการ optimize ให้เข้ากับ ARM มากยิ่งขึ้น อย่างเช่น Go version 1.18 ที่มีการปรับปรุงการส่งฟังก์ชั่นเป็นอาร์กิวเมนต์ในรูปแบบใหม่ที่ทำให้ได้ performance มามากขึ้นกว่า 10% นั่นเอง ref: Making your Go workloads up to 20% faster with Go 1.18 and AWS Graviton

2/ Workload Transition

เมื่อ software ของเรานั้นรองรับการทำงานบน AWS Graviton กันเป็นที่เรียบร้อยแล้ว ถัดไปเราจะมาดูว่าการเปลี่ยน workload ของเราไปใช้เป็น AWS Graviton มีขั้นตอนเบื้องต้นยังไง ในที่นี้เราจะขอยกตัวอย่างเป็น AWS EKS ซึ่งเป็น Kubernetes Platform สำหรับบริหารและจัดการ Container workload ที่ใช้กันอย่างแพร่หลายในปัจจุบัน เมื่อพร้อมแล้วเรามาเริ่มกันที่

• Container Image จากข้อที่หนึ่ง เมื่อเราได้ทดลอง compile หรือเปลี่ยน runtime ของภาษาที่เราใช้งาน เราก็จะมาทำสิ่งที่เรียกว่า Multi-arch container images ที่ทำให้ Image ของเราทำงานได้บนหลาย CPU architectures (arm64 และ amd64) ซึ่งสามารถใช้เครื่องมืออย่าง Docker Buildx มาช่วยในขั้นตอนนี้ได้เลยครับ

• Deploy เมื่อ build เสร็จก็ต้อง deploy ถูกต้องไหมครับ ใน EKS เราสามารถสร้าง Node Group ใหม่โดยใช้ instance type ที่เป็นประเภท Graviton ได้เลย วิธีดูว่า Instance Type ไหนเป็น AWS Graviton ก็คือตัวลงท้ายในประเภทจะเป็นตัว g เช่น t4g.mediumครับ หลังจากนั้นเราก็ควร taint node group นี้ไว้ด้วยแล้วก็ค่อยไปใส่ toleration ให้ service ที่พร้อมสำหรับการรันบน AWS Graviton ถึงเข้ามาใช้งานได้ครับ

    tolerations:
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

  จริงๆแล้ววิธีการย้าย workload มีค่อนข้างหลากหลายครับ นอกจาก Taint and Toleration ก็ยังมี Node label selector และ Node affinity อีกด้วย ซึ่งเราสามารถใช้งานร่วมกันเผื่อให้ได้ผลลัพธ์ตามที่ควรจะเป็นได้ครับ

  นอกจากการรันให้ถูก node แล้ว เรายังสามารถผสาน technique ที่เกี่ยวกับ Traffic splitting ได้อีกด้วย ทำให้เราสามารถลองแบ่ง Traffic จำนวนหนึ่งมารันบน AWS Graviton เพื่อทำการทดสอบอะไรบางอย่างก่อนจะย้ายไปใช้จริง 100% ได้ครับ

• Testing เราจะรู้ได้ยังไงหล่ะว่าการมาใช้ AWS Graviton ทำให้ระบบเราได้ Performance ที่มากขึ้นและ Latency ลดลงเหมือนที่คนอื่นเขาเล่ากันมา คำตอบคือการทำ Testing ครับ หากว่าระบบเรามี script สำหรับการทำ Smoke Test เราก็สามารถนำมาทดลองรันกับ Service ที่ทำงานอยู่บน AWS Graviton เผื่อ Monitor ผลลัพธ์ได้เลยครับ

  อย่างไรก็ตาม การใช้งาน AWS Graviton ไม่ได้หมายความว่าเราจะได้ประสิทธิภาพเพิ่มขึ้นกันตลอดทุกครั้งนะครับ เพราะอย่างที่เรากล่าวกันไปในหัวข้อก่อน ว่าถ้าเวอร์ชั่นของภาษาที่เราใช้ยังไม่ได้ Optimize มาสำหรับ CPU ประเภท ARM อาจจะทำให้ประสิทธิภาพลดลงก็เป็นได้ โดยในส่วนนี้เราสามารถใช้เครื่องมือที่เรียกว่า Flame Graphs มาดู stack frame ของ application ว่ามันช้าลงที่ส่วนไหนเพื่อทำการ optimize เพิ่มเติมได้ครับ

ทั้งหมดนี้ก็เป็นเพียงขั้นตอนคร่าวๆเท่านั้น ทุกคนสามารถเข้าไปอ่านเรื่อง Transition Guide เพิ่มเติมเพื่อขั้นตอนและวิธีการวางแผนที่ถูกต้องมากขึ้นครับ

3/ Managed Services

นอกจาก workload ของเราเองแล้ว เรายังสามารถใช้งานเจ้า Graviton กับ Managed services ต่างๆของ AWS ได้ด้วยนะ ซึ่งในส่วนนี้เราไม่ต้องทำอะไรเลยครับ สามารถ upgrade แล้วก็ enjoy ได้เลย ลองเข้าไปดูรายละเอียดของแต่ล่ะ managed services ที่เราต้องการใช้งานได้เลยครับ

สรุป

ถ้าหากว่าคุณเริ่มที่จะสนใจ AWS Graviton แล้วล่ะก็ ลองเข้าไปที่ AWS Graviton Fast Start ซึ่งเป็นโปรแกรมสำหรับการย้าย workload ของเรามาอยู่บน AWS Graviton ซึ่งมีตัวอย่างของ Serverless, Container, Database และ Caching ครับ

ขอพลังของ ARM จงสถิตอยู่กับทุกคนครับ ⚔️

Continue readings

• https://github.com/aws/aws-graviton-getting-started
• https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/transitioning-your-service-or-application.html %%

พอดีได้มีโอกาสไปร่วมงานเปิดตัว AWS Bangkok Local zone ที่โรงแรม Anantara Siam Bangkok Hotel เมื่อวันที่ 31 มกราที่ผ่านมา เลยลองสรุปสาระสำคัญจากงานมาฝากครับ

ทำไมต้อง Local Zone?

เกริ่นก่อนสำหรับคนที่ยังไม่เข้าใจ Local zone มากนัก เอาง่ายๆเลย มันก็คือโซนท้องถิ่นนั่นเอง! อย่าเพิ่งเอ๊ะไป เราลองเข้าไปดูใน AWS Global Infrastructure ได้บอกไว้ว่า Region ประกอบไปด้วย Avaliability zone ซึ่งบ่อยครั้งก็อยู่ห่างจาก User มากเกินไป จึงทำให้เกิด Local Zone ที่มีคุณลักษณะคล้าย Availibility Zone หลายประการ แต่เข้าไปอยู่ใกล้ User มากขึ้นเพื่อรองรับการทำงานที่ต้องการ latency ต่ำนั่นเอง ซึ่ง Bangkok Local Zone ก็ถือเป็น Zone ภายใต้ ap-southeast-1 หรือ Singapore (อนาคตก็จะไม่ได้อยู่ใน Thailand region นะ)

Latency ที่ตอบโจทย์

จากรูปของการทดสอบที่ลองสั่ง ping ไปยังเครื่องใน ap-southeast-1 (รูปซ้าย) ที่ใช้เวลาประมาณ 27ms กับฝั่ง local zone (รูปขวา) ประมาณ 4ms จะเห็นได้ว่า local zone ให้ latency ที่ต่ำกว่าประมาณ 6 เท่าเลยทีเดียว!

และเนื่องจาก Bangkok Local zone จะอยู่ภายใต้ Region Singapore จึงใช้ Network backbone เดียวกัน ทำให้เราสามารถติดต่อกับ Service ที่มีตามเดิมใน region ได้ปกติ ไม่ได้วิ่งออก public network แต่อย่างใด

Services ที่รองรับ

ณ ปัจจุบัน Services ที่พร้อมให้บริการบน Local Zone (วงกลมส้ม) จะยังมีไม่มากแต่ทาง AWS ก็มีแพลนจะเพิ่ม Services ที่สามารถใช้งานบน Local zone ขึ้นอีกในอนาคต (วงกลมขาว)

และถึงแม้ว่า services จะยังไม่มากนัก แต่ก็ค่อนข้างเพียงพอต่อความต้องการในการยกระดับ system ที่มี latency sensitive ให้มี performance ที่มากขึ้นได้ และนอกจาก Services ในข้างต้น เรายังสามารถใช้ AWS Marketplace Partner ภายใน Local zone ได้เหมือน region ปกติอีกด้วย

ราคาเท่าไหร่กันนะ

พูดกันมาถึงขนาดนี้ หลายๆท่านคงเตรียมเปิด console ไปกดสร้างหรือเตรียมแผนงานย้ายระบบมาอยู่บน Local zone กันเป็นแน่แท้ แต่ก่อนจะไปขั้นนั้น ลองมาดูค่าใช้จ่ายเมื่อเทียบกับ compute ทั่วไปบน region กันก่อน

|EC2 (Region)|EC2 (Local Zone)| |---|---|---| |Instance (c5.2xlarge) / hours|$0.392|$0.549| |EBS (gp2) / GB|$0.12|$0.246|

จะเห็นได้ว่าราคาของ compute บน local zone สูงกว่าบน region ประมาณ 40% เลยทีเดียว นอกจากนี้เรายังเสียค่า Network Transfer ทั้ง In และ Out $0.08/GB อีกด้วย (ดูราคาเพิ่มเติม) นอกจากราคาที่เพิ่มขึ้นแล้วยังมี Instance Type และ Disk Type ให้เลือกค่อนข้างจำกัด ฉะนั้น เราจะมาพูดคุยถึง Use case ของการนำ Local zone มาใช้ให้เกิดความคุ้มค่าในด้านไหนได้บ้าง ช่วงท้ายของบทความ

การมาของ Thailand Region

ยังไม่หมดเพียงเท่านั้น ภายในงานยังมีการพูดถึงการมาในอนาคตของ Thailand Region เพราะ AWS ถึงกับทุ่มเงินจำนวน 190 ล้านบาท เพื่อเข้ามาทำ Region ในประเทศไทยกันเลยทีเดียว

และภายในงานยังมีคำถามที่น่าสนใจดังนี้

กล่าวโดยสรุปคือ BKK Local zone จะเป็นส่วนต่อขยายของ Singapore และจะไม่มีอะไรเกี่ยวข้องกับ TH Region ในอนาคต ถึงแม้ว่า TH Region จะเสร็จและพร้อมใช้งาน ก็จะไม่มีการย้าย BKK Local Zone มาที่ TH region แต่อย่างใด

ใช้ให้ถูกงาน

ลองมาดูตัวอย่างหรือ Use case การนำ Local zone มาใช้เพื่อให้เกิดประโยชน์กันดีกว่า

• Game

  • ตัวอย่างจากค่ายเกม Supercell เจ้าของเกมยอดนิยมอย่าง Clash of Clans ที่ต้องการให้บริการ Game Server ให้ผู้เล่นมี latency ที่ต่ำเพื่อให้ได้รับประสบการณ์การเล่นเกมที่ดีมากยิ่งขึ้น

• Content creation

  • อันนี้ยกตัวอย่างถึงบริษัท Netflix ที่มีการเอา Local zone ไปให้บริการสำหรับ service ที่ run latency sensitive เช่นการ live production video editing ให้ใกล้กับเหล่า artist มากยิ่งขึ้น

• Remote broadcasting

  • Esports Engine สามารถพัฒนาระบบที่มี latency ต่ำและมี performance ที่ดีขึ้นสำหรับการ broadcasting video ด้วยการวาง AWS Local zone ให้ใกล้กับผู้ใช้งาน พร้อมทั้งสามารถ scale ไปสู่ Global ได้ทันทีอีกด้วย

สรุป 🗒️

สำหรับองค์กรที่คิดจะกระโดดเข้ามาสู่การใช้ Bangkok Local zone จะต้องมี Use case ที่เหมาะสม เพราะนอกจากจะมีราคาที่มากกว่าเดิมแล้ว Service หลายๆตัวก็ยังไม่พร้อมให้บริการ ณ ขณะที่เขียนบทความนี้ แต่ก็ถือว่าเป็นสิ่งที่น่าสนใจมาก ที่จะนำมาช่วยพัฒนาระบบที่ต้องการ latency ที่ต่ำเพื่อให้ได้ performance ที่มากขึ้น ใครต้องการจะทดสอบก็สามารถลองทำตามบทความจาก AWS ได้เลย

ถ้าชอบก็อย่าลืมกดติดตามบทความถัดๆไปด้วยนะ ขอบคุณครับ 🙇🏻‍♂️

disclaimer: This post focuses on how fun chaos engineering can be. This does not cover the principal and real practicalities of chaos engineering.

What is Chaos Engineering?

Chaos engineering is the process of testing a distributed computing system to ensure that it can withstand unexpected disruptions. It relies on concepts underlying chaos theory, which focuses on random and unpredictable behavior.

TechTarget

The meaning is relatively straightforward, In short, It’s is “rude to your cluster and hope it can survive”. But the real world of Chaos Engineering has a lot of topics for measuring the metrics that you can ensure your experiment runs successfully or not.

Leave it behind, Because in this article we will talk only about the FUN part of chaos engineering, But it might not be fun for everyone 🤣

What is Gamification?

The practice of making activities more like games in order to make them more interesting or enjoyable.

Cambridge Dictionary

For example, In the classroom, the teacher can give you a point that you can use to exchange with a special score or some benefits like gaining more time to do the homework than other people and the point will give to the student that participated and answers in the classroom. Does it sound like the game?

Ready for the fun?

The formula is -> Chaos engineering + Gamification = Fun (Maybe)!

To make it fun, We need to make the process more like a game. That you can play a game while doing the chaos engineering at the same time.

A lot of the interesting projects to make chaos engineering more fun has created on GitHub, Thanks for the open sources.

Are you ready? Let’s get started.

⚠️ Warning: Do with your own risk!

1. Kube Doom

KubeDoom is The next level of chaos engineering! Kill pods inside your Kubernetes cluster by shooting them in Doom! - KubeDoom

2. KubeInvaders

Gamified Chaos Engineering Tool for Kubernetes - KubeInvaders

3. Kube Chaos

A chaos engineering style game where you seek out and destroy Kubernetes pods, twinstick shmup style - Kube Chaos

119267327-07a41c80-bbe6-11eb-87ec-25ee0f96e669.mp4

Summary

These are the example projects that I found to make chaos engineering fun. If you find more interesting projects please tell me. But also please note that this is not the real principle of chaos engineering. It’s just fun to implement the game with some chaos engineering concepts. To make it right, You need to understand more in the context of what you are doing and experiment for the result that you are looking for to improve the durability of your system.

Have fun! and see you in the next post.

เกริ่นนำกันซักนิด

ถ้าหากคุณหลงเข้ามาโดยที่ยังไม่รู้ว่าเจ้า Obsidian คืออะไร เราขอสรุปสั้นๆว่า Obsidian ก็คือ Note taking เจ้านึงที่เน้นเรื่อง Privacy first หรือก็คือ note ของเรา เราดูแลเอง บวกกับการจด Note ในแบบที่ Developer ชอบก็คือ Markdown style นั่นเอง เท่านั้นยังไม่พอ community ยังช่วยกันทำ plugin เพื่อให้เจ้า Obsidian มีความสามารถที่มากขึ้น ถือเป็น note taking app ที่มี feature ที่หลากหลาย ทำงานแบบ offline ได้ ที่สำคัญ ทั้งหมดที่กล่าวมานั้น ฟรี!!!!!!!!

แต่เดี๋ยวก่อน ถึงแม้จะบอกว่าโปรแกรมนี้ฟรี แต่ก็มีจุดที่เขาหารายได้อยู่เหมือนกันด้วยการขายบริการหรือ add-ons แยกเพื่อใช้คู่กับ Obsidian ซึ่งมีอยู่สองส่วน ส่วนแรกก็คือระบบของการ Publish ที่จะช่วยให้เราสามาระแชร์ Note ของเราออกมาเป็น Link ที่สามารถเปิดดูได้ผ่าน Internet และส่วนที่สองคือการ Sync ที่จะช่วยให้โน๊ตของเราเหมือนกับ device เครื่องอื่นๆ เช่นแก้จากคอมไปดูในมือถือเป็นต้น

ตอนนี้เราอาจจะมีคำถามว่า แล้วถ้าไม่อยากจ่ายเงินหล่ะ ไหนบอกฟรี? โอเค ไม่เป็นไร ผมมีข่าวดีสำหรับสาย Apple ทุกท่านก็คือ iCloud ใน iOS มัน mount file system ลงในเครื่องให้เลย ทำให้เราเปิด vault ของเราบน iCloud drive ได้ทั้งใน Mac แล้วก็ iPhone และ Sync กันได้เลยโดยที่ไม่ต้องทำอะไร แต่สำหรับสาย Android อย่างกระผมนั้นก็ไม่ต้องน้อยใจกันไป ตามมาดูวิธีต่างๆที่เราสามารถทำได้กัน

เป็นที่แน่นอนว่าถ้ามีระบบ plugin หรือการเก็บโน๊ตของเราลงบนเครื่องเราเองอยู่แล้ว เราย่อมมีทางเลือก ซึ่งวันนี้เราจะมาเสนอสี่ทางเลือกที่จะช่วยให้เราสามารถใช้งาน Obsidian บนหลายๆ device ได้พร้อมๆกัน (Publish ก็ทำแบบฟรีๆได้นะ แต่วันนี้เราจะมาโฟกัสกับการ Sync กันก่อน) เริ่มกันที่วิธีแรก

1/ Autosync

วิธีแรกคือการใช้ Cloud Storage อย่าง Google Drive เข้ามาช่วย Sync ข้อมูลให้เราโดยที่ใน PC หรือ Laptop เราก็ลงพวก File sync ของ Cloud ใดก็ได้ที่เราชื่อชอบ เช่น Google Drive for Desktop หลังจากนั้นก็ใช้แอพ AutoSync เข้ามาช่วย sync ข้อมูลเหล่านั้นมาลงบนโทรศัพท์ของเราได้เลย

สำหรับวิธีนี้ การตั้งค่าจะค่อนข้างง่าย เพียงแค่ login กับทาง Google Drive ทั้งสองอุปกรณ์ของเรา ตัว folder ก็จะเริ่ม Sync กันโดยอันตโนมัติ เพียงแต่ข้อเสียของวิธีคือมันไม่ real-time เพราะเราต้องตั้ง interval ว่าจะให้มันทำการ Sync ทุกๆกี่นาที ซึ่งถ้าเราตั้งถี่มากๆก็หมายถึง Battery ที่จะโดนสูบเข้าไปมากเช่นกัน หรือถ้าเราต้องการ sync มาทันทีก็ต้องมากด sync เองแบบ manual ครับ นอกจากแอพ AutoSync ก็ยังมีอีกเจ้านึงที่ชื่อ FolderSync สามารถไปลองโหลดมาทดสอบกันดูได้เลยครับ

นี่ก็จบกันไปแล้วกับวิธีแรก ซึ่งถ้าหากว่าวิธีแรกมันง่ายไป เชิญคุณอ่านต่อไปได้เลยครับ แต่ถ้ามันยากไปคุณอาจจะต้องทบทวนว่าจะจ่ายเงินให้ Obsidian ดีไหมแทนแล้วหล่ะ เพราะหลังจากนี้จะเริ่มยากขึ้น และใช้ความรู้ทางด้านสายงาน IT พอสมควร ซึ่งจะมีความเสี่ยงต่อการสูญหายของข้อมูลด้วย หากคุณจัดการมันได้ไม่ดีพอ ถ้าคุณอ่านแล้วยังไม่กลัว ก็เชิญไปที่วิธีถัดไปได้เลยครับ

2/ Remotely Save (Plugin)

อย่างที่กล่าวไปในตอนต้นว่า Obsidian เปิด API ให้นักพัฒนาสามารถเข้าไปทำ plugin เพื่อเสริมความสามารถได้เต็มที่ เลยทำให้มีคนทำ plugin ที่ชื่อว่า Remotely Save ที่สามารถ Sync note ของเราเข้ากับ Cloud services ต่างๆได้ ซึ่งในปัจจุบันก็รองรับ S3, Dropbox, Webdav และ OneDrive ซึ่งการใช้งานก็เพียงแค่ติดตั้งและทำการ connect plugin เข้ากับ cloud service ที่เราต้องการก็เป็นที่เรียบร้อยแล้ว ที่เหลือเราก็เลือกได้เลยว่าต้องการให้ Sync ทุกๆกี่นาที หรือให้ทำการ Sync ทุกครั้งที่เปิดแอพขึ้นมาก็ได้เช่นกัน

เราอาจจะสังเกตว่าจะเริ่มมีคำเตือนมากขึ้นเมื่อเราเริ่มที่จะใช้ plugin เพราะการ Sync note ของเราระหว่างเครื่องอื่นๆก็คือการเขียนทับ ลบไฟล์ต่างในเครื่องของเรา ดังนั้นหากคุณหรือตัว plugin เองทำบางอย่างผิดพลาดไป ก็อาจจะเกิดการสูญหายของข้อมูลได้เช่นกัน ดังนั้นเราเลยต้องมีวิธี backup ข้อมูลของเราเช่นกัน

3/ Git (Plugin)

อันนี้อาจจะไม่เชิง sync ซะทีเดียว แต่เรายังสามารถใช้เผื่อ backup vault ของเราได้อีกด้วย เพราะ Git ก็คือ version control system ตัวนึงที่ทำให้เราสามารถติดตามการเปลี่ยนแปลงของไฟล์เราได้ การใช้งาน plugin นี้ก็เหมือนวิธีก่อนหน้าเลยครับ เข้าไปติดตั้ง plugin Obsidian Git แล้วก็ทำการ enable กับ config ให้เรียบร้อยก็จะใช้งานได้ทันทีครับ ซึ่ง plugin ตัวนี้สามารถตั้งค่าได้ครอบคลุมการใช้งานที่หลากหลายมากๆ เช่นให้ backup แล้ว push ไปที่ remote repository ของเรา ในทุกๆเสลาที่เรากำหนดหรือทุกครั้งที่เราเปิดโปรแกรมขึ้นมา หรือคอย pull ดูอยู่เรื่อยๆว่ามีอัพเดตอะไรมาใหม่หรือไม่ แต่เนื่องด้วยความที่ Git เป็นความรู้เฉพาะทาง ทำให้การตั้งค่าในโทรศัพท์มือถือก็มีขั้นตอนที่เพิ่มขึ้นมาไม่น้อยเช่นกัน การขาดความเข้าใจอาจจะทำให้ข้อมูลหลุดหรือสูญหายได้เลยทีเดียว ฉะนั้นหากคุณไม่ได้เข้าใจว่า Git คืออะไรก็ขอให้ข้ามมันไปก่อนล่ะกันครับ

4/ Syncthing

เข้าสู่ดาวเด่นของงานในวันนี้ ซึ่งเป็นวิธีที่ผมชอบมากที่สุดเลยก็ว่าได้ เพราะเจ้าตัว Syncthing มันทำงานแบบ real-time ทำให้เมื่อเราแก้ไฟล์ที่ laptop ของเรา โทรศัพท์ก็จะเห็นการเปลี่ยนแปลงนั้นแบบไวมากๆ เรียกว่ามีข้อดีเต็มไปหมด แต่ก็ใช่ว่าจะไม่มีข้อเสีย ข้อเสียหลักๆของ Syncthing นั่นก็คือการที่ตัวมันเป็นอีกโปรแกรมนึงเลยที่เราต้องดูแลและตั้งค่ามัน เพราะแท้จริงแล้ว Syncthing เป็นเพียงโปรแกรมที่เอาไป sync ไฟล์ระหว่างสองเครื่อง ไม่ได้มีส่วนเกี่ยวข้องอะไรกับ Obsidian แต่อย่างใด ซึ่งในการใช้งานเราจะต้องทำการเพิ่ม remote devices ให้อุปกรณ์ของเรารู้จักกันเสียก่อน หลังจากนั้นเราจึงสามารถ share folder ของเราไปให้อุปกรณ์อื่นได้ และข้อมูลระหว่างสองอุปกรณ์ก็จะ sync กันอยู่เสมอตราบเท่าที่โปรแกรม Syncthing ยังคงทำงานอยู่ครับ และการใช้งานโปรแกรมนี้ก็ควรระมัดระวังเรื่องของการตั้งค่าให้ดีเพราะค่อนข้างเฉพาะทางมากๆครับ

หากคุณสนใจก็ลองอ่านเรื่องความปลอดภัยของเจ้าโปรแกรมตัวนี้ดูก่อนได้ แล้วก็ค่อยๆอ่าน document ในส่วนที่เราสงสัยตามไปเรื่อยๆครับ เมื่อเข้าใจพื้นฐานของมัน โปรแกรมนี้ก็เป็นอีกเครื่องมือที่ประยุกต์ใช้ในสถานการณ์อื่นๆได้ดีเช่นกันครับ

สรุป

หลังจากที่เราเต็มอิ่มกับวิธีทั้งหมดที่มีกันไปแล้ว หากเพื่อนๆมีวิธีอื่นที่น่าสนใจก็ comment บอกกันได้เลยครับ ซึ่งจากที่เราเห็นบางวิธีก็ง่าย แต่ก็อาจจะไม่ได้ตามที่เราต้องการ หรือบางวิธีที่ดูจะได้ตามสิ่งที่เราต้องการก็ดูยากเย็นเหลือเกินกว่าจะได้มันมา ถ้าทำไม่ดี หรือทำอะไรผิดไปบางขั้นตอนก็อาจเป็นเหตุให้ข้อมูลสูญหายกันได้อีกด้วย ฉะนั้นการจ่างเงินในบางครั้งก็ดูเป็นทางออกที่ไม่เลวครับ 😅

ถ้าคุณชอบบทความแบบนี้ อย่าลืมกดติดตาม เพื่อรับการแจ้งเตือนบทความถัดไปด้วยนะครับ 🙇🏻‍♂️

References

• https://help.obsidian.md/Getting+started/Sync+your+notes+across+devices

เกริ่นนำ

มีช่วงนึงที่เราหันไปใช้ Linux แบบจริงๆจังๆ จนเราได้ไปลอง Distro ตัวหนึ่งที่ชื่อ Arch Linux ในตอนนั้นเราก็ตกหลุมรักเข้ากับมนต์เสน่ห์แปลกๆของมัน ไม่ว่าจะการอัพเดตที่มีมาบ่อยจนรู้สึกหวาดกลัว หรือ package manager ที่แสนจะอัจฉริยะอย่างเจ้า pacman ทำให้เราต้องการนำมันกลับมาใช้งานใน WSL บนคอมเครื่องหลักของเรา แต่หลังจากที่ลอง search บน Windows Store เราเจอแต่ unofficial package ที่ไม่ได้อัพเดตมาหลายเดือนแล้ว เลยไปลองหาข้อมูลเพิ่มจนได้ใจความว่า ในปัจจุบันมี project open-source อยู่ตัวหนึ่งชื่อว่า wsldl ที่เราไว้ติดตั้ง rootfs หรือ disk image (ext4 vhdx) ใดๆก็ตามลงใน WSL ซึ่งเขาก็ได้ทำ rootfs สำหรับ Arch Linux ไว้ด้วยให้เราใช้ติดตั้งลงบน WSL ได้เลย ซึ่ง Package บน Windows Store ที่เราเจอก็เอาอันนี้ไปใช้นี่แหละ แต่เดี๋ยวเราจะมาลงกันเองเพื่อความ up-to-date!

สำหรับคนที่ไม่รู้จัก WSL มันก็คือเครื่องมือที่ช่วยให้นักพัฒนาสามารถใช้งานความสามารถของ Linux ได้โดยที่ไม่จ้องไปปวดหัวกับการทำ virtual machine หรือการทำ dual boot แต่ก็มาปวดหัวกับ WSL อยู่ดีนะ 😂

ลงมือ

ด้วยความที่เจ้าของโปรเจ็คนี้ได้เตรียมอะไรหลายๆอย่างไว้ให้เราแล้ว ทำให้การติดตั้งนั้นมีหลายวิธีและค่อนข้างง่าย และในวันนี้เราจะใช้วิธีการติดตั้งผ่าน appx เพราะว่าง่ายมว๊าก เราสามารถทำตามขั้นตอนนี้ได้เลย

1. เข้าไปดาวน์โหลดตัวติดตั้งที่เป็น .appx กับตัว .cer มาไว้ที่เครื่องเราซึ่งเราก็เลือกแบบ AppX หรือ Online-AppX ก็ได้จะแตกต่างแค่ Online จะเป็นไฟล์ขนาดนั้นเล็ก จะมีการโหลดเพิ่มระหว่างการติดตั้งเฉยๆ
2. พอทำการโหลดทุกอย่างเสร็จเรียบร้อยก็ทำการ Install Cer เข้าไปก่อนเผื่อเป็นการยืนยันว่าเราเชื่อถือผู้พัฒนานี้ ก็คลิกตาม docs นี้ได้เลย
3. ขั้นตอนสุดท้ายก็ดับเบิ้ลคลิก .appx เพื่อทำการ install ก็เป็นอันเสร็จพิธีครับ

appx ก็คือ package file ของ windows ที่เอาไว้ใช้แจกจ่ายสำหรับการติดตั้ง application ที่เป็น Universal Windows Platform (UWP) ส่วนมากใช้สำหรับนำแอพขึ้น Windows Store

นอกจาก Arch Linux แล้ว เรายังสามารถเอา wsldl มาใช้ได้กับทุก distro ที่เราต้องการได้เลย สามารถใช้กับ CPU ประเภท ARM ได้อีกด้วย

ขอให้สนุกกับ WSL ครับ 👋

References

• https://learn.microsoft.com/en-us/windows/wsl/install
• https://github.com/yuk7/wsldl
• https://github.com/yuk7/ArchWSL
• https://wsldl-pg.github.io/ArchW-docs/