Це гостьовий допис у блозі, написаний разом із Заком Россманом з Alcion.
Alcion, платформа резервного копіювання як послуги (BaaS), керована перш за все безпекою, допомагає адміністраторам Microsoft 365 швидко й інтуїтивно захищати дані від кіберзагроз і випадкової втрати даних. У разі втрати даних клієнтам Alcion потрібно шукати метадані для резервних копій (файлів, електронних листів, контактів, подій тощо), щоб вибрати певні версії елементів для відновлення. Alcion використовує Служба Amazon OpenSearch щоб надати своїм клієнтам точну, ефективну та надійну можливість пошуку в цьому резервному каталозі. Платформа є багатокористувачем, що означає, що Alcion вимагає ізоляції даних і надійної безпеки, щоб гарантувати, що орендарі можуть шукати лише власні дані.
Сервіс OpenSearch — це повністю керований сервіс, який спрощує розгортання, масштабування та керування OpenSearch у хмарі AWS. OpenSearch — це пошуковий і аналітичний пакет із відкритим вихідним кодом під ліцензією Apache-2.0, який включає OpenSearch (пошукова, аналітична система та векторна база даних), інформаційні панелі OpenSearch (користувальницький інтерфейс для візуалізації та утиліти) і плагіни, які надають розширені можливості, такі як корпоративні -рівень безпеки, виявлення аномалій, спостережливість, попередження та багато іншого. Amazon OpenSearch Serverless це варіант безсерверного розгортання, який спрощує використання OpenSearch без налаштування, керування та масштабування доменів OpenSearch Service.
У цій публікації ми розповідаємо про те, як впровадження OpenSearch Serverless дозволило Alcion задовольнити вимоги до масштабу, зменшити накладні витрати на роботу та захистити дані своїх клієнтів шляхом застосування ізоляція орендаря у своєму середовищі з кількома клієнтами.
Керовані домени OpenSearch Service
Для першої ітерації своєї пошукової архітектури Alcion обрала опцію розгортання керованих доменів у OpenSearch Service і змогла запустити робочу функцію пошуку менш ніж за місяць. Щоб відповідати своїм вимогам щодо безпеки, масштабу та оренди, вони зберігали дані для кожного орендаря в спеціальному індексі та використовували тонкий контроль доступу у OpenSearch Service, щоб запобігти витоку даних між клієнтами. Зі збільшенням робочого навантаження інженери Alcion відстежували використання домену OpenSearch за допомогою наданого Amazon CloudWatch метрики, вносячи зміни для збільшення пам’яті та оптимізації своїх обчислювальних ресурсів.
Команда Alcion використовувала кілька функцій керованих доменів OpenSearch Service, щоб покращити свою операційну позицію. Вони представили псевдоніми індексів, які надають єдине псевдонім для доступу (читання та запису) до кількох базових індексів. Вони теж налаштували Індекс управління станом (ISM), щоб допомогти їм контролювати свій життєвий цикл даних, змінюючи індекси на основі розміру індексу. Разом політики ISM і псевдоніми індексів були необхідні для масштабування індексів для великих орендарів. Використовувався також Альціон шаблони індексів визначати сегменти для кожного індексу (поділу) своїх даних, щоб автоматизувати життєвий цикл даних і підвищити продуктивність і стабільність своїх доменів.
На наступній схемі архітектури показано, як Alcion налаштував свої керовані домени OpenSearch.
На наведеній нижче діаграмі показано, як дані Microsoft 365 індексувалися в індексах клієнта та запитувалися з них. Alcion реалізував автентифікацію запитів, надаючи облікові дані основного користувача OpenSearch з кожним запитом API.
OpenSearch Serverless огляд і параметри моделі оренди
Керовані домени OpenSearch Service забезпечили стабільну основу для пошукової функції Alcion, але команді потрібно було вручну надати ресурси для доменів для їхнього пікового навантаження. Це залишило простір для оптимізації витрат, оскільки робоче навантаження Alcion велике — існують великі варіації в кількості транзакцій пошуку та індексації за секунду як для окремого клієнта, так і в цілому. Щоб зменшити витрати та операційне навантаження, команда звернулася до OpenSearch Serverless, який пропонує можливість автоматичного масштабування.
Щоб використовувати OpenSearch Serverless, першим кроком є створення колекції. А збір це група індексів OpenSearch, які працюють разом для підтримки певного робочого навантаження або варіанту використання. Обчислювальні ресурси для колекції, які називаються OpenSearch Compute Units (OCU), спільно використовуються між усіма колекціями в обліковому записі, які мають спільний ключ шифрування. Пул OCU автоматично збільшується та зменшується відповідно до вимог індексування та пошукового трафіку.
Рівень зусиль, необхідний для переходу з домену, керованого OpenSearch Service, на OpenSearch Serverless, був досяжним завдяки тому факту, що колекції OpenSearch Serverless підтримують ті самі API та бібліотеки OpenSearch, що й керовані домени OpenSearch Service. Це дозволило Alcion зосередитися на оптимізації моделі оренди для нової архітектури пошуку. Зокрема, команді потрібно було вирішити, як розділити дані орендарів у колекціях та індексах, збалансувавши безпеку та загальну вартість володіння. Інженери Alcion у співпраці з командою OpenSearch Serverless, розглянули три моделі оренди:
- Модель силосу: створіть колекцію для кожного орендаря
- Модель пулу: створіть єдину колекцію та використовуйте єдиний індекс для кількох орендарів
- Модель Bridge: створіть єдину колекцію та використовуйте єдиний індекс для кожного клієнта
Усі три варіанти дизайну мали переваги та компроміси, які необхідно було враховувати при розробці остаточного рішення.
Модель силосу: створіть колекцію для кожного орендаря
У цій моделі Alcion створював би нову колекцію кожного разу, коли новий клієнт входив на їх платформу. Хоча дані орендарів будуть чітко розділені між колекціями, цей параметр було відхилено, оскільки час створення колекції означав, що клієнти не зможуть створювати резервні копії та шукати дані одразу після реєстрації.
Модель пулу: створіть єдину колекцію та використовуйте єдиний індекс для кількох орендарів
У цій моделі Alcion створить єдину колекцію для кожного облікового запису AWS та індексує дані, що стосуються орендаря, в одному з багатьох спільних індексів, що належать до цієї колекції. Спочатку об’єднання даних орендарів у спільні індекси було привабливим з точки зору масштабу, оскільки це призводило до найбільш ефективного використання ресурсів індексів. Але після подальшого аналізу Alcion виявив, що вони будуть цілком у межах квоти індексу колекції, навіть якщо виділять один індекс для кожного орендаря. Вирішивши цю проблему щодо масштабованості, Alcion вибрав третій варіант, оскільки розміщення даних клієнта у виділених індексах призводить до більшої ізоляції клієнта, ніж модель спільного індексу.
Модель Bridge: створіть єдину колекцію та використовуйте єдиний індекс для кожного клієнта
У цій моделі Alcion створить єдину колекцію для кожного облікового запису AWS і створить індекс для кожного із сотень орендарів, якими керує цей обліковий запис. Призначивши кожному клієнту спеціальний індекс і об’єднавши ці індекси в одну колекцію, Alcion скоротив час адаптації для нових клієнтів і розділив дані орендарів у чітко відокремлені сегменти.
Впровадження контролю доступу на основі ролей для підтримки кількох орендарів
OpenSearch Serverless пропонує багатоточковий, успадкований набір елементів безпеки, що охоплює доступ до даних, доступ до мережі та шифрування. Alcion скористався всіма перевагами OpenSearch Serverless політики доступу до даних для впровадження керування доступом на основі ролей (RBAC) для кожного індексу клієнта з такими деталями:
- Призначте індекс із загальним префіксом і ідентифікатором клієнта (наприклад,
index-v1-<tenantID>
) - Створіть виділений Управління ідентифікацією та доступом AWS (IAM), яка використовується для підписання запитів до колекції OpenSearch Serverless
- Створіть політику доступу до даних без сервера OpenSearch, яка надає дозволи на читання та запис документів у виділеному індексі клієнта ролі IAM для цього клієнта
- Запити API OpenSearch до індексу клієнта підписуються тимчасовими обліковими даними, що належать до ролі IAM для конкретного клієнта
Нижче наведено приклад політики доступу до даних без сервера OpenSearch для фіктивного клієнта з ідентифікатором t-eca0acc1-12345678910
. Ця політика надає доступ для читання та запису документу ролі IAM до виділеного доступу клієнта.
На наведеній нижче діаграмі архітектури показано, як Alcion реалізував індексування та пошук ресурсів Microsoft 365 за допомогою підходу спільної колекції OpenSearch Serverless.
Нижче наведено зразок фрагмента коду для надсилання запиту API до колекції OpenSearch Serverless. Зверніть увагу, як клієнт API ініціалізується за допомогою об’єкта підписувача, який підписує запити за допомогою того самого принципала IAM, який пов’язано з політикою доступу до даних OpenSearch Serverless із попереднього фрагмента коду.
Висновок
У травні 2023 року Alcion розгорнув свою пошукову архітектуру на основі спільної колекції та спеціальної моделі індексу на кожного клієнта в усіх робочих і підготовчих середовищах. Команда змогла розібрати складний код і операційні процеси, які були призначені для масштабування керованих доменів OpenSearch Service. Крім того, завдяки можливостям автоматичного масштабування OpenSearch Serverless Alcion зменшив свої витрати на OpenSearch на 30% і очікує сприятливого масштабування профілю витрат.
На своєму шляху від керованого до безсерверного OpenSearch Service компанія Alcion виграла від свого початкового вибору керованих доменів OpenSearch Service. Під час подальшої міграції вони змогли повторно використовувати ті самі OpenSearch API та бібліотеки для своїх колекцій OpenSearch Serverless, які вони використовували для свого керованого домену OpenSearch Service. Крім того, вони оновили свою модель оренди, щоб скористатися перевагами політик доступу до даних OpenSearch Serverless. Завдяки OpenSearch Serverless вони змогли без особливих зусиль адаптуватися до масштабних потреб своїх клієнтів, одночасно забезпечуючи ізоляцію клієнта.
Щоб дізнатися більше про Alcion, відвідайте їх сайт.
Про авторів
Зак Россман є членом технічного персоналу Alcion. Він є технічним лідером для платформ пошуку та AI. До Alcion Зак працював старшим інженером із програмного забезпечення в Okta, розробляючи основні продукти ідентифікації персоналу та керування доступом для команди Directories.
Нірадж Джетлі — менеджер із розробки програмного забезпечення Amazon OpenSearch Serverless. Нірадж керує кількома командами рівня даних, відповідальними за запуск Amazon OpenSearch Serverless. До роботи в AWS Нірадж понад 15 років очолював кілька груп продуктів і інженерів як технічний директор, віце-президент з розробки та керівник відділу управління продуктами. Нірадж отримав понад 15 нагород за інновації, у тому числі був названий найкращим ІТ-директором року в 2014 році та 100 найкращих ІТ-директорів у 2013 та 2016 роках. Він часто виступає на кількох конференціях, його цитують NPR, WSJ і The Boston Globe.
Джон Хендлер є старшим головним архітектором рішень у Amazon Web Services у Пало-Альто, Каліфорнія. Джон тісно співпрацює з OpenSearch і Amazon OpenSearch Service, надаючи допомогу та вказівки широкому колу клієнтів, які мають робочі навантаження з пошуку та аналітики журналів, які вони хочуть перенести в AWS Cloud. До того як приєднатися до AWS, кар’єра Джона як розробника програмного забезпечення включала 4 роки кодування великомасштабної пошукової системи електронної комерції. Джон має ступінь бакалавра мистецтв Пенсільванського університету, а також ступінь магістра наук і доктора філософії з комп’ютерних наук і штучного інтелекту в Північно-західному університеті.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. Автомобільні / електромобілі, вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- BlockOffsets. Модернізація екологічної компенсаційної власності. Доступ тут.
- джерело: https://aws.amazon.com/blogs/big-data/alcion-supports-their-multi-tenant-platform-with-amazon-opensearch-serverless/
- : має
- :є
- $UP
- 10
- 100
- 15 роки
- 15%
- 16
- 2013
- 2014
- 2016
- 2023
- a
- Здатний
- МЕНЮ
- доступ
- управління доступом
- рахунки
- точний
- через
- пристосовувати
- Додатково
- адреси
- Адміністратори
- Прийняття
- просунутий
- Перевага
- після
- AI
- ВСІ
- виділено
- дозволяти
- дозволено
- Також
- хоча
- Amazon
- Amazon Web Services
- an
- аналіз
- аналітика
- та
- виявлення аномалії
- API
- Інтерфейси
- підхід
- архітектура
- ЕСТЬ
- штучний
- штучний інтелект
- мистецтва
- AS
- At
- привабливий
- Authentication
- автоматичний
- автоматизувати
- автоматично
- нагороди
- AWS
- BAAS
- назад
- резервна копія
- Балансування
- заснований
- BE
- оскільки
- було
- буття
- Переваги
- між
- Блог
- тіло
- Бостон
- обидва
- широкий
- тягар
- але
- by
- CA
- званий
- CAN
- можливості
- можливості
- кар'єра
- випадок
- каталог
- Зміни
- вибір
- вибір
- вибрав
- CIO
- клієнт
- тісно
- хмара
- код
- Кодування
- співробітництво
- збір
- Колекції
- загальний
- комплекс
- що включає
- обчислення
- комп'ютер
- Інформатика
- Занепокоєння
- конференції
- налаштувати
- вважається
- Наші контакти
- контекст
- контроль
- управління
- Core
- Коштувати
- витрати
- покриття
- створювати
- створення
- створення
- Повноваження
- CTO
- клієнт
- Клієнти
- кібер-
- інформаційні панелі
- дані
- доступ до даних
- втрати даних
- Database
- вирішувати
- присвячених
- дефолт
- запити
- розгортання
- розгортання
- description
- дизайн
- проектування
- деталі
- Виявлення
- Розробник
- розвивається
- розробка
- каталоги
- документ
- документація
- домен
- домени
- вниз
- кожен
- легко
- електронної комерції
- ефективний
- зусилля
- повідомлення електронної пошти
- включений
- шифрування
- виконання
- двигун
- інженер
- Машинобудування
- Інженери
- забезпечувати
- забезпечення
- підприємства
- Навколишнє середовище
- середовищах
- помилка
- помилки
- Ефір (ETH)
- Навіть
- Event
- Події
- еволюціонували
- приклад
- чекає
- факт
- риси
- Файли
- остаточний
- Перший
- Сфокусувати
- після
- для
- Вперед
- знайдений
- фонд
- частий
- від
- Повний
- повністю
- функціональність
- далі
- Крім того
- отримання
- GitHub
- земну кулю
- гранти
- Group
- гість
- Гість-блог
- керівництво
- було
- Мати
- he
- голова
- допомога
- допомагає
- тримає
- Як
- How To
- HTML
- HTTP
- HTTPS
- Сотні
- IAM
- ID
- Особистість
- управління ідентифікацією та доступом
- if
- негайно
- здійснювати
- реалізовані
- імпорт
- удосконалювати
- in
- включені
- У тому числі
- Augmenter
- індекс
- індексований
- покажчики
- інформація
- початковий
- спочатку
- інновація
- інноваційні нагороди
- Інтелект
- інтерфейс
- в
- введені
- ізоляція
- IT
- пунктів
- ітерація
- ЙОГО
- приєднання
- джон
- подорож
- JPG
- json
- ключ
- великий
- масштабний
- запуск
- запуск
- вести
- Веде за собою
- Витоку
- Led
- залишити
- менше
- рівень
- libraries
- Життєвий цикл
- як
- пов'язаний
- погрузка
- журнал
- від
- РОБОТИ
- Робить
- вдалося
- управління
- менеджер
- управління
- вручну
- багато
- майстер
- матч
- Може..
- засоби
- означав
- Зустрічатися
- член
- метадані
- Метрика
- Microsoft
- Microsoft 365
- мігрувати
- мігруючи
- модель
- місяць
- більше
- найбільш
- рухатися
- багато
- множинний
- ім'я
- Названий
- необхідно
- Необхідність
- необхідний
- потреби
- мережу
- Доступ до мережі
- Нові
- Північно-західний університет
- Зверніть увагу..
- номер
- об'єкт
- of
- Пропозиції
- ОКТА
- on
- На борту
- ONE
- тільки
- з відкритим вихідним кодом
- працювати
- оперативний
- Оптимізувати
- оптимізуючий
- варіант
- or
- Нам
- з
- над
- огляд
- власний
- власність
- сторінка
- Пало-Альто
- Peak
- Пенсільванія
- для
- продуктивність
- дозвіл
- Дозволи
- перспектива
- платформа
- Платформи
- plato
- Інформація про дані Платона
- PlatoData
- plugins
- Політика
- політика
- басейн
- пошта
- запобігати
- попередній
- первинний
- Головний
- попередній
- процеси
- Product
- Управління продуктом
- Production
- Продукти
- профіль
- захист
- забезпечувати
- за умови
- Постачальник
- забезпечення
- забезпечення
- швидко
- діапазон
- Читати
- читач
- зменшити
- Знижений
- Реєстрація
- надійний
- запросити
- запитів
- вимагається
- Вимога
- Вимагається
- вирішене
- ресурс
- ресурси
- відповідь
- відповідальний
- відновлення
- результати
- повертати
- знову використовувати
- Роль
- Прокат
- рухомий
- Кімната
- Правила
- то ж
- масштабованість
- шкала
- Масштабування
- наука
- сфера
- Пошук
- Пошукова система
- Грати короля карти - безкоштовно Nijumi логічна гра гри
- другий
- безпечний
- безпеку
- відправка
- старший
- Без сервера
- обслуговування
- Послуги
- комплект
- кілька
- Поділитись
- загальні
- Шоу
- підпис
- підписаний
- Ознаки
- простий
- один
- Розмір
- уривок
- So
- Софтвер
- розробка програмного забезпечення
- Інженер-програміст
- рішення
- Рішення
- Гучномовець
- конкретний
- конкретно
- Стабільність
- стабільний
- Персонал
- стан
- Крок
- зберігання
- зберігати
- рядок
- сильний
- більш сильний
- набір
- підтримка
- Підтримуючий
- Опори
- Приймати
- прийняті
- команда
- команди
- технології
- технічний
- тимчасовий
- орендар
- ніж
- Дякую
- Що
- Команда
- їх
- Їх
- Ці
- вони
- третій
- це
- загрози
- три
- час
- до
- разом
- прийняли
- топ
- Усього:
- трафік
- Transactions
- операції в секунду
- Опинився
- що лежить в основі
- одиниць
- університет
- Університет Пенсільванії
- оновлений
- використання
- використання випадку
- використовуваний
- користувач
- Інтерфейс користувача
- використовує
- використання
- утиліта
- Цінності
- через
- візит
- візуалізації
- vp
- хотіти
- було
- we
- Web
- веб-сервіси
- ДОБРЕ
- були
- коли б ні
- який
- в той час як
- ВООЗ
- всі
- з
- в
- без
- Work
- працювати разом
- Трудові ресурси
- працює
- б
- запис
- WSJ
- рік
- років
- зефірнет