7 речей, які я хотів би знати до того, як розгортати проєкт з AWS в Китаї

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Всім привіт. Мене звати В’ячеслав Компанієць, я Director of Infrastructure & Operations в компанії MEV.

У цій статті хочу розказати про «граблі», по яких я пройшовся, ще перебуваючи на посаді System Engineer, та розгортаючи проєкт з використанням провайдера хмарних послуг AWS в Китаї.

Одразу дисклеймер — цей проєкт реалізувався в рамках нашої співпраці з великим американським ритейлером, який ще до початку повномасштабного вторгнення вирішив відкрити новий магазин в Китаї. І досвід, який я описуватиму в статті, може бути цікавий читачу з точку зору наочного прикладу, які відмінності застосування технологій можуть бути при розгортанні проєктів в різних географічних регіонах.

Згідно з певними тамтешніми законодавчими обмеженнями, тримати та обробляти будь-які дані можна лише в межах країни. Тому, щоб користувачі з цього регіону могли скористатись застосунком, було вирішено створити його копію з усією інфраструктурою вже в AWS у Китаї.

На перший погляд, здавалося б: ну це такий самий AWS, все те ж саме, що може піти не так?

Швидкий огляд статей давав кілька порад щодо того, на які моменти варто звернути увагу: чи є там взагалі необхідний вам сервіс і в яких саме регіонах він підтримується, було багато згадок про ICP (про це трохи далі), багато скарг на швидкість тощо.

Але в нашому випадку це зовсім не лякало: всі необхідні сервіси наявні, проблеми зі швидкістю стосуються лише трафіку з-за меж країни та не вплинуть негативно на користувацький досвід, а ліцензію, як і сам AWS-акаунт, замовник вже мав.

Тут я, можливо, десь переоцінив себе та недооцінив важливість повноцінного детального аналізу, оскільки субʼєктивно здавалося, що короткого дослідження буде цілком достатньо. Я помилився.

І ось тепер, вже маючи деякий досвід, хочу поділитись з вами кількома моментами, які б я дуже хотів знати ще до того, як взявся за цю роботу.

Ліцензія ICP

З цим особисто мені не довелось зіткнутись, оскільки замовник вже мав ліцензію та AWS-акаунт. Але цей момент дуже важливий для початку і його варто коротко висвітлити. Детальнішу інформацію можна отримати, наприклад, тут, але краще звʼязатися зі своїм провайдером з приводу цього питання.

Створення нового акаунту AWS в Китаї сильно відрізняється від процедури для глобальної версії, за якою новий обліковий запис може створити будь-хто за 2 хвилини.

Що потрібно для цього у Китаї:

• Мати зареєстровану юридичну особу або фізичну особу з громадянством та реєструвати акаунт на неї.
• Щоб публікувати або завантажувати будь-який контент, потрібно мати ліцензію ICP (Internet Content Provider).
• Для отримання цієї ліцензії ICP потрібно надати своєму хостинг- або хмарному провайдеру необхідну інформацію про власника: доменне ім’я, IP-адресу, вміст та призначення сайту чи застосунку, обовʼязково контактну особу з питань безпеки тощо.

Тільки після цього ви матимете законне право опублікувати ваш застосунок або навіть просто сайт-візитівку. Питанням безпеки приділяється особлива увага, оскільки захист даних користувачів є одним з найвищих пріоритетів. Ну і як зазначено вище, це має бути фізична чи юридична особа зареєстрована та фізично присутня в Китаї. Таким чином отримати ліцензію іноземцям неможливо. Заради справедливості варто зазначити, що ці правила стосуються не тільки AWS, а й будь-якого іншого провайдера послуг чи хостингу.

AWS Global vs AWS China

Отже, одну з відмінностей між ними, повʼязану з реєстрацією ми вже знаємо. Але це тільки верхівка айсберга.

По суті AWS Global та AWS China — це два абсолютно незалежні один від одного сервіси, які ніяк не поєднані між собою та не мають спільних ресурсів. Це не просто ще один регіон, як, наприклад, з Європою, а зовсім інший сетап. Це стає зрозуміло відразу, оскільки і домен в них теж свій — https://console.amazonaws.cn/ (на відміну від глобального https://console.aws.amazon.com/).

Наведу кілька прикладів з кейсами, які неможливі для реалізації між Global та China акаунтами, використовуючи вбудовані механізми:

• управління організацією та, як наслідок, консолідований білінг;
• кросакаунт IAM ролі та політики;
• реплікація, піринг тощо.

Це доволі незручно, особливо якщо мова йде про один і той самий продукт, як в нашому випадку. Проте варто враховувати цю особливість і при необхідності «спілкування» вашого застосунку з іншими ресурсами в глобальному AWS. Це може бути реалізовано тільки у форматі зовнішнього доступу, без використання вбудованих можливостей.

Доступні сервіси та їх обмеження

Список доступних сервісів доволі просто знайти, наприклад, тут. Це одна з речей, на які однозначно варто звернути увагу на етапі аналізу. Але те, що необхідний вам сервіс існує в цьому регіоні ще не означає, що він працює точно так само, як і в глобальному.

Так, нам потрібен був CloudFront. Цей сервіс підтримується в регіоні Ningxia (cn-northwest-1), проте, коли прийшов час його налаштувати, то виявилось, що він не підтримує сертифікати з ACM і їх не можна вказати для своєї дистрибʼюції, а підтримує він тільки завантаження сертифікатів користувачем. Тобто єдиний варіант — десь виписати собі сертифікат і завантажити його прямо в налаштуваннях CloudFront.

Багато хто вимушений купувати їх або ж використовувати обхідні шляхи у вигляді сертифікатів Let’sEncrypt, хоч це і «костиль» та вимагає більше часу в майбутньому на підтримку інфраструктури.

Цікаво те, що до EC2 Load Balancer’ів без проблем можна прив’язати сертифікат, виданий Amazon — там подібного обмеження немає.

Також варто передивитись документацію до сервісів, які плануєте використовувати. Оскільки, наприклад, в EKS є багато корисної інформації щодо деплою службових чартів в регіонах cn-north-1 та cn-northwest-1(можна ознайомитись за цим посиланням), де вказано який Account ID варто використовувати для публічних Registry компонентів.

Низька швидкість зʼєднання

Про цю проблему (чи точніше особливість) роботи сервісів ми знали заздалегідь, тому не були здивовані.

Потрібно розуміти, що швидкість з’єднання низька тільки за умови, коли трафік йде ззовні, а всередині країни все працює більш-менш нормально. А оскільки продукт розгортався для користувачів саме цього регіону, то на їх досвід це не мало вплинути.

В реальності це все ж викликало кілька проблем, в основному для команди розробників та інфраструктурних інженерів, які знаходились в США та Україні. Адже розгортання інфраструктури та управління нею, збірка, деплой та навіть моніторинг через це працюють нестабільно.

Процеси CI\CD іноді падали з помилками через неможливість отримати необхідні залежності або просто по таймауту, моніторинг міг мати багато хибно-позитивних спрацювань, а тестування продукту займало більше часу ніж зазвичай.

Також, за моїми особистими спостереженнями, швидкість доступу залежить ще й від часового проміжку. Так, наприклад, у період з 8:00 до 17:00 за Києвом швидкість прийнятна (хоч і все одно повільна у порівнянні з глобальним AWS). А от у період з 17:00 до 5:00 — найгірша. З чим це пов’язано я не знаю, але для себе вивів правило — деплой в кінці робочого дня роботи не варто.

Недоступність ресурсів

Проблеми зі швидкістю та іноді стабільністю з’єднань це ще не все. Глобальнішою виявилась проблема з недоступністю деяких ресурсів. Це вже пов’язано не стільки з обмеженнями AWS, скільки з обмеженнями самих провайдерів доступу до мережі інтернет. Привіт, Great China Firewall.

Проблеми, з якими я особисто стикнувся:

• недоступна частина ресурсів з Docker Hub (часто через проблеми зі швидкістю);
• недоступний Google Container Registry та частина інших сервісів Google;
• проблеми з доступом до деяких репозиторіїв npm або python (також часто через проблеми зі швидкістю).

Це лише те, з чим я працював, але впевнений, що перелік значно більший.

Тому частину образів, які потрібні були для роботи (той же fluent-bit, наприклад) довелось перезаливати на ECR в Китай, а для частини інших — шукати доступні альтернативи.

Тут головне не піддаватись ілюзії простоти рішення та розуміти, що доступні дзеркала в Китаї є і їх багато, проте часто вони містять застарілі або навіть заражені шкідливим кодом версії образів чи пакетів, а тому можуть бути небезпечними. Обирайте дзеркала з розумом або створюйте свої registry за потреби.

Ну і, звичайно, VPN там недоступний.

Підтримка китайських регіонів вашими інструментами

Тепер перейдемо до менш очевидних, але дуже важливих речей — інструментів. Так, регіони cn-north-1 та cn-northwest-1 можуть просто не підтримуватися вашими інструментами, і це, особисто для мене, було найболючішим.

Наприклад, для зручності розробники користувались Apex UP і для запуску проєкту локально, і для деплою на всі оточення. Виявилось, що він не підтримує ці регіони. Звісно, на момент написання статті у нашої команди вже було кілька Issue на GitHub з цього приводу, але прогресу по них немає вже близько року.

Також не зайвим буде переконатись, що ваші Terraform модулі також мають підтримку цього регіону, тому що, як виявилось, всі IAM ролі в Китаї мають трохи інший вигляд, а саме arn:aws-cn:iam::012345678901:role.

Подібна участь спіткала й Terraform код або модулі, яким потрібно sts:AssumeRole, оскільки для цього регіону Service Principal також відрізняється — має бути ec2.amazonaws.com.cn.

Те ж саме вплинуло і на побудову CI процесу. Ми використовуємо Bitbucket pipelines у якості CI і в налаштуваннях OIDC вашого пайплайну він також не сприймає ролі arn:aws-cn:iam::... через те, що парсер просто не знає такої форми запису і чекає на стандартний arn:aws:iam::....

Тому з особливою увагою віднесіться до всіх ваших інструментів та перевірте заздалегідь, чи працюватимуть вони.

CDN

Це те, що ви точно захочете використовувати, навіть якщо не планували, через низьку швидкість з’єднання і особливо за межами країни. І тут теж є моменти, які варто зауважити.

Раніше я вже згадував про особливості імпорту сертифікатів до CloudFront. Часто як альтернативу йому (і, до речі, кращу) обирають AliCDN від AliCloud. Це доволі великий та відомий хмарний провайдер азійського регіону.

Притому, що він дотримується всіх тих самих правил відкриття акаунтів, він має більшу мережу серверів у країнах Сходу та надає кращий сервіс. Тому зверніть на нього увагу, якщо вирішите додати CDN до вашого продукту.

So, long story short

• Зареєструйте акаунт AWS China та отримайте ліцензію ICP. Для цього вам потрібні будуть або юридична, або фізична особа громадянина в цій країні.
• Памʼятайте, що AWS Global та China не мають спільних ресурсів, це два повністю самостійні та незалежні сервіси.
• Перевіряйте всі аспекти роботи необхідного вам сервісу. Навіть якщо він і існує в цьому регіоні, не факт, що все працюватиме так само як і в глобальному. Зокрема, CloudFront не підтримує сертифікати з ACM.
• Закладайте деякий запас у свій час на будь-які роботи з AWS в Китаї через повільне з’єднання та плануйте роботи заздалегідь.
• Перевіряйте доступність усіх необхідних вам ресурсів.
• Перевіряйте усі ваші інструменти на предмет сумісності та можливості роботи з Китайським регіоном.

P. S. Дякую Сергію Носалю за допомогу і у написанні цієї статті, і у розгортанні проєкту.