From GitHub Raw to Azure Blob: How We Migrated Our Blog's Image Storage

ဒီနေ့ ကျွန်တော့်ရဲ့ Author တွေအတွက် အလုပ်ရှုပ်သက်သာစေမယ့် Feature အသစ်လေးတစ်ခု ထည့်ပေးဖြစ်ခဲ့ပါတယ်။ အဲ့ဒါကတော့ Image Upload Button လေးပါ။

ဒါက ကျွန်တော်ကိုယ်တိုင် End User (ကျွန်တော့်ရဲ့ Author တွေ) နေရာကနေ ခံစားပြီး လုပ်ပေးဖြစ်တာပါ။ ကျွန်တော်ကိုယ်တိုင်လည်း Article ရေးတဲ့အခါ Image တွေထည့်ချင်ရင်

• GitHub Repo တစ်ခုထဲမှာ ပုံကို Upload လုပ်ရ၊
• GitHub Raw URL ကို သွားယူရ၊
• ရလာတဲ့ URL ကို Markdown Format နဲ့ ပြန်စစ်ပြီး ထည့်ရနဲ့ တော်တော်လေး အလုပ်ရှုပ်ပါတယ်။

အခုဆိုရင် အောက်က Video လေးထဲကလိုမျိုး "Upload Image" ကို နှိပ်လိုက်တာနဲ့ ပုံ Upload လုပ်ပြီးတာနဲ့ တစ်ပြိုင်နက်တည်း Markdown URL တစ်ခုကို ချပေးမှာဖြစ်ပါတယ်။ အဲ့ဒီ URL ကို Editor ထဲမှာ အလွယ်တကူ copy paste လုပ်လိုက်ရုံပဲဆိုတော့ အတော်လေးအသုံးဝင်သွားပါတယ်။

ဒါဆိုရင် ကျွန်တော် နောက်ကွယ်မှာ ဘယ်လိုအလုပ်လုပ်ထားလဲ ဆိုတာ ရှင်းပြပါမယ်။ ကျွန်တော် အရင်တုန်းကဆိုရင် tech-blog-avatars ဆိုတဲ့ GitHub Repo တစ်ခုထဲမှာ Author တွေရဲ့ Image တွေရော Article Cover Image တွေရော အကုန်လုံးကို စုထည့်ခဲ့တာဖြစ်တယ်။

1class Author(models.Model):
2    user = models.OneToOneField(User, on_delete=models.CASCADE, related_name="author_profile")
3    name = models.CharField(max_length=100)
4    bio = models.TextField(blank=True)
5    avatar = models.URLField(blank=True)
6    avatar_path = models.CharField(max_length=500, blank=True)

ဒါက ကျွန်တော့်ရဲ့ Author Model ထဲက Field တစ်ချို့ဖြစ်ပါတယ်။ Migration လုပ်တဲ့နေရာမှာ ကျွန်တော် အရင်က ပုံတွေကိုလည်း မထိခိုက်စေချင်ဘူး။ Migrate လုပ်ဖို့ဆိုရင်လည်း အလုပ်ရှုပ်တယ်။ အဲ့ဒါကြောင့် avatar ကို URLField အဖြစ်ပဲ သုံးထားတယ်။ အရင်ကဟာတွေ ကိုလည်း "https://raw.github/user/repo/image.png" ပုံစံနဲ့ပဲ ဆက်လက် သိမ်းထားနိုင်မယ်။

Azure Blob ထဲကဟာတွေ ကိုလည်း "https://myblog.blob.core.windows.net/avatars/author1.png" ဆိုတဲ့ ပုံစံနဲ့ သိမ်းနိုင်တယ်။ ဒီလိုလုပ်ခြင်းအားဖြင့် အရင်ဟာတွေကို မထိခိုက်တော့သလို၊ အသစ်တွေကိုလည်း Azure Blob မှာထားနိုင်တယ်။

avatar_path ဆိုတာက Blob ရဲ့ Path ကို သိမ်းထားတာဖြစ်ပြီး၊ Base URL ကို Code ထဲမှာ "https://myblog.blob.core.windows.net" ဆိုပြီး သတ်မှတ်ထားတာမလို့ avatar_path, cover_image_path, article_images_path ဆိုပြီး ခွဲခြားထားတာဖြစ်တယ်။

Junior တွေအတွက် သိထားသင့်တဲ့ အချက်များ

Junior Developer အဖြစ်ကနေ စတင်မယ့်သူတွေ၊ ဒါမှမဟုတ် File Management ပိုင်းမှာ ရွေးချယ်မှု မှားနေသေးတဲ့သူတွေ သေချာနားလည်စေချင်လို့ ထပ်ပြောပြချင်ပါတယ်။ Application ရဲ့ Image တွေကို Local Disk (C: Drive, D: Drive) ဒါမှမဟုတ် Linux File Path တွေမှာထားတာကို တတ်နိုင်သမျှ ရှောင်ရမယ်။

အရင်ခေတ်တုန်းကလို Database Query တွေသုံးပြီး Code ထဲကနေ Image တွေကို ပြန်ခေါ်ထုတ်တာမျိုးတွေ လုပ်ရင် Performance ကို ထိခိုက်စေတယ်။ ဘာကြောင့်လဲဆိုတော့

• Server က Image တွေကို Disk ထဲမှာ လိုက်ရှာဖွေရတယ်။
• File System ကနေ ပုံတွေကို ဖတ်ယူရတဲ့ Process က ပုံမှန်အားဖြင့် Cloud Storage (Blob) ကနေ တိုက်ရိုက်ခေါ်တာထက် အချိန် ပိုကုန်တယ်။
• Image တွေကို Database ထဲမှာ Binary Data (ဥပမာ: BLOB Type) နဲ့ သိမ်းတာက လုံးဝ မလုပ်သင့်တဲ့ အရာမျိုးဖြစ်တယ်။
• Database ကို လေးစေပြီး Query Speed ကို သိသိသာသာ နှေးကွေးစေတယ်။

Database ရဲ့ အဓိကတာဝန်က Structure Data ကို ကိုင်တွယ်ဖို့ပါ။ Image တွေ မဟုတ်ဘူး။ User အရေအတွက်များလာပြီး တစ်ပြိုင်နက်တည်း ပုံတွေ အများကြီး တောင်းဆိုတဲ့အခါ Server ရဲ့ CPU နဲ့ Memory ဝန်ပိပြီး system တစ်ခုလုံး Crash သွားနိုင်တယ်။ Production အတွက် လုံးဝ အန္တရာယ်များတယ်။

Cloud ပေါ်မှာတောင် Disk တွေဟာ Blob တွေထက် အများကြီး စျေးပိုကြီးတယ်။ Performance လည်း ပိုနှေးနိုင်တယ်။ ဒါကြောင့် Image တွေလို အရာတွေကို သီးခြား Cloud Storage Solution တွေ (Azure Blob, AWS S3) မှာပဲထားပါ။ ဒါမှ Server ကိုလည်း ဝန်မပိစေဘဲ ပိုက်ဆံလည်း သက်သာမယ်။

Azure Blob Storage ဆိုတာ ဘာလဲ

Azure Blob Storage ဆိုတာ Microsoft Azure ကပေးတဲ့ Object Storage Service တစ်ခုပါ။ Structure မပါတဲ့ Data (Unstructured Data) တွေဖြစ်တဲ့ Image တွေ၊ Video တွေ၊ Log File တွေ၊ Backup File တွေ စတာတွေကို အင်တာနက်ကနေတစ်ဆင့် Access လုပ်နိုင်အောင် သိမ်းဆည်းပေးတဲ့ နေရာတစ်ခုပဲ။

Container နဲ့ Blob ဆိုတာ ဘာလဲ

Container က Folder လိုပဲ။ Blob တွေကို စုစည်းထားတဲ့ အစုအဝေးပဲ။ ဥပမာ- avatars container၊ article-covers container စသည်ဖြင့် ခွဲထားနိုင်တယ်။ Blob ကတော့ အဲ့ဒီ Container ထဲမှာ ရှိတဲ့ File တစ်ခုချင်းစီ (ဥပမာ: profile.jpg၊ header.png) ကို ခေါ်တာပါ။

Blob Storage မှာ Access ခွင့်ပြုချက်ကို သတ်မှတ်လို့ရတယ်။ ယေဘုယျအားဖြင့်

1. Private - ကျွန်တော်တို့ owner ပဲ ကြည့်လို့ရမယ်။ azure access ရှိတဲ့ လူမျိုးကိုခေါ်တာ။
2. Public (Anonymous) ဒါက Image တွေလို Static Assets တွေအတွက် မဖြစ်မနေ ဖွင့်ပေးရတယ်။ ဘာလို့လဲဆိုတော့ စာဖတ်သူတွေက ပုံရဲ့ URL ကို သိရုံနဲ့ ဝင်ကြည့်လို့ရမှ အဆင်ပြေမှာလေ။ ကျွန်တော့် Article ပုံတွေအတွက်ဆိုရင် Anonymous Read ကို ဖွင့်ထားပေးရတာပေါ့။

ကုန်ကျစရိတ်

သိမ်းဆည်းထားတဲ့ ပမာဏ (Storage) နဲ့ User တွေ ပုံတွေ ဆွဲယူသုံးစွဲတဲ့ ပမာဏ (Egress/Traffic) ပေါ်မူတည်ပြီး တွက်တာ။ ကျွန်တော့် Blog တစ်ခုစာ 10GB လောက်ဆိုရင် တစ်လကို $1-$3 လောက်နဲ့ အေးဆေး သုံးနိုင်တယ်။ Blob Storage တွေဟာ ကမ္ဘာတစ်ဝန်းက Data Center တွေမှာ ပျံ့နေတာ။ ကျွန်တော်ကတော့ CDN တောင် မခံထားရသေးဖူး။ ဒီအတိုင်းတောင် GitHub Raw ထက် အများကြီး မြန်နေပြီ။

code ထဲကနေ ချိတ်ဆက်ပုံ

ကျွန်တော်တို့ Code ထဲကနေ Azure ကို ချိတ်ဖို့အတွက် "secrets" တွေ လိုတယ်။

• Connection String ဒါက အလွယ်ဆုံးနည်းလမ်းပဲ။ သူ့မှာ Account နာမည်၊ key နဲ့ အခြား လိုအပ်တာတွေ အကုန်ပါပြီးသား။ ဒီ String တစ်ခုလုံးကို Configuration File ထဲမှာ ဒါမှမဟုတ် Code ထဲမှာ ထည့်ပေးလိုက်ရုံနဲ့ Azure နဲ့ ချိတ်ဆက်လို့ ရပြီ။ ဒီ key က မိမိရဲ့ storage account တစ်ခုလုံးနဲ့ သက်ဆိုင်တာမလို့ သေချာသိမ်းထားရမယ်။ ဘယ်သူ့ကိုမှ မပေးရဖူး။
• နောက်တစ်မျိုးကတော့ SAS Token (Shared Access Signature) သူ့ကိုကျ connection string ကို မပေးချင်တဲ့အခါ သုံးတဲ့ နည်းလမ်း။ SAS Token က ခွင့်ပြုချက်တွေကို ကန့်သတ်နိုင်တယ်။ ဘယ် Container ကိုပဲ Access လုပ်၊ read access ပဲလား expire period ကရောဘယ်လောက်လဲ ဘယ်အချိန်အထိပဲ သုံးခွင့်ရမလဲ စသဖြင့် သတ်မှတ်ပေးလို့ရတယ်။ ဒါကြောင့် ပိုပြီး လုံခြုံတယ်။

ဒီနေ့ share ပေးခဲ့တာကတော့ junior တွေအတွက် image storage အကြောင်းနဲ့ blob storage အကြောင်းပဲဖြစ်ပါတယ်။ ကျေးဇူးတင်ပါတယ်ခင်ဗျာ