Це гостьовий пост, написаний у співавторстві з Рагу Боппанною з Vanguard.
At авангарднийбізнес-напрямок Enterprise Advice покращує результати для інвесторів завдяки цифровому доступу до першокласних, персоналізованих і доступних фінансових консультацій. Вони зробили це можливим, зокрема, завдяки економії на масштабах у всьому світі для інвесторів за допомогою надзвичайно стійкої та ефективної технічної платформи. Для цього робочого навантаження Vanguard вибрав архітектуру з кількома регіонами, щоб допомогти захистити від погіршення регіональних служб. Для цілей високої доступності існує потреба зробити дані, які використовуються робочим навантаженням, доступними не лише в основному регіоні, але й у вторинному регіоні з мінімальною затримкою реплікації. У разі погіршення обслуговування в основному регіоні рішення має мати можливість перемикатися на вторинний регіон із якомога меншою втратою даних і можливістю відновити прийом даних.
Vanguard Cloud Technology Office і AWS співпрацюють, щоб створити інфраструктурне рішення на AWS, яке відповідає їхнім вимогам щодо стійкості. Багаторегіональне рішення забезпечує надійний механізм відновлення після збоїв із вбудованою можливістю спостереження та відновлення. Рішення також підтримує передачу даних із кількох джерел у різні потоки даних Kinesis. Рішення наразі розгортається для різних напрямків бізнес-команд, щоб покращити стійкість їхніх робочих навантажень.
Варіант використання, який обговорюється тут, вимагає зміни даних Capture (CDC) для потокової передачі даних із віддаленого джерела даних (мейнфрейм DB2) до Потоки даних Amazon Kinesis, оскільки від цих даних залежить бізнес-можливість. Kinesis Data Streams — це повністю керований, широкомасштабований, надійний і недорогий потоковий сервіс, який може безперервно отримувати та передавати великі обсяги даних із багатьох джерел і робить дані доступними для використання протягом мілісекунд. Служба створена для високої стійкості та використовує кілька зон доступності для обробки та зберігання даних.
Рішення, яке обговорюється в цій публікації, пояснює, як AWS і Vanguard впровадили інновації для створення стійкої архітектури для досягнення своїх цілей високої доступності.
Огляд рішення
Розчин використовує AWS Lambda для копіювання даних із потоків даних Kinesis у первинному регіоні до додаткового регіону. У разі будь-яких порушень служби, що впливають на конвеєр CDC, процес відновлення після збоїв перетворює вторинний регіон на основний для виробників і споживачів. Ми використовуємо Глобальні таблиці Amazon DynamoDB для контрольних точок реплікації, що дозволяє відновити потокове передавання даних із контрольної точки, а також підтримує прапор конфігурації основного регіону, який запобігає нескінченному циклу реплікації тих самих даних вперед і назад.
Рішення також забезпечує споживачам Kinesis Data Streams гнучкість використання основного або будь-якого додаткового регіону в межах одного облікового запису AWS.
Наступна діаграма ілюструє еталонну архітектуру.
Розглянемо кожен компонент докладніше:
- Процесор CDC (виробник) – У цій еталонній архітектурі виробник розгортається на Обчислювальна хмара Amazon Elastic (Amazon EC2) як у первинному, так і в додатковому регіонах, активний у первинному регіоні та в режимі очікування у вторинному регіоні. Він фіксує дані CDC із зовнішнього джерела даних (наприклад, базу даних DB2, як показано в архітектурі вище) і передає потоки до потоків даних Kinesis у основному регіоні. Vanguard використовує 3rd партійний інструмент Qlik Replicate як їх процесор CDC. Він створює добре сформоване корисне навантаження, включаючи мітку часу фіксації DB2 для потоку даних Kinesis, на додаток до фактичних даних рядка з віддаленого джерела даних. (
example-stream-1
у цьому прикладі). Наступний код є зразком корисного навантаження, що містить лише первинний ключ запису, який змінився, і мітку часу фіксації (для простоти решта даних рядка таблиці не показана нижче):{ "eventSource": "aws:kinesis", "kinesis": { "ApproximateArrivalTimestamp": "Mon July 18 20:00:00 UTC 2022", "SequenceNumber": "49544985256907370027570885864065577703022652638596431874", "PartitionKey": "12349999", "KinesisSchemaVersion": "1.0", "Data": "eyJLZXkiOiAxMjM0OTk5OSwiQ29tbWl0VGltZXN0YW1wIjogIjIwMjItMDctMThUMjA6MDA6MDAifQ==" }, "eventId": "shardId-000000000000:49629136582982516722891309362785181370337771525377097730", "invokeIdentityArn": "arn:aws:iam::6243876582:role/kds-crr-LambdaRole-1GZWP67437SD", "eventName": "aws:kinesis:record", "eventVersion": "1.0", "eventSourceARN": "arn:aws:kinesis:us-east-1:6243876582:stream/kds-stream-1/consumer/kds-crr:6243876582", "awsRegion": "us-east-1" }
Розшифроване значення Base64
Data
полягає в наступному. Фактичний запис Kinesis міститиме всі дані рядка рядка таблиці, який змінився, на додаток до первинного ключа та мітки часу фіксації.{"Key": 12349999,"CommitTimestamp": "2022-07-18T20:00:00"}
Команда
CommitTimestamp
вData
Поле використовується в контрольній точці реплікації та має вирішальне значення для точного відстеження того, скільки даних потоку було скопійовано до вторинного регіону. Потім контрольну точку можна використовувати для полегшення перемикання процесора (виробника) CDC і точного відновлення виробництва даних із мітки часу контрольної точки реплікації.Альтернатива використанню віддаленого джерела даних
CommitTimestamp
(якщо недоступний) є використанняApproximateArrivalTimestamp
(що є міткою часу, коли запис фактично записується в потік даних). - Лямбда-функція міжрегіональної реплікації – Функція розгортається як у первинних, так і в вторинних регіонах. Він налаштований із зіставленням джерела події з потоком даних, що містить дані CDC. Цю ж функцію можна використовувати для копіювання даних кількох потоків. Він викликається пакетом записів із потоків даних Kinesis і реплікує пакет до цільової області реплікації (яка надається через середовище конфігурації Lambda). З міркувань вартості, якщо дані CDC активно створюються лише в основному регіоні, зарезервований паралелізм функції у вторинному регіоні можна встановити на нуль і змінити під час регіонального відновлення після відмови. Функція має Управління ідентифікацією та доступом AWS (IAM) дозволи ролі, щоб виконувати такі дії:
- Читання та запис у глобальні таблиці DynamoDB, які використовуються в цьому рішенні, в межах одного облікового запису.
- Читання та запис у потоки даних Kinesis в обох регіонах в межах одного облікового запису.
- Опублікувати спеціальні показники в Amazon CloudWatch в обох регіонах в межах одного облікового запису.
- Контрольна точка реплікації – Контрольна точка реплікації використовує глобальну таблицю DynamoDB як у первинному, так і в вторинному регіонах. Він використовується функцією міжрегіональної реплікації Lambda для збереження мітки часу фіксації останнього запису реплікації як контрольної точки реплікації для кожного потоку, налаштованого для реплікації. Для цієї публікації ми створюємо та використовуємо глобальну таблицю під назвою
kdsReplicationCheckpoint
. - Конфігурація активного регіону – Активний регіон використовує глобальну таблицю DynamoDB як у первинному, так і в вторинному регіонах. Для реплікації конфігурації використовується власна можливість міжрегіональної реплікації глобальної таблиці. Він попередньо заповнюється даними про те, який регіон є основним для потоку, щоб запобігти реплікації назад до основного регіону за допомогою функції лямбда в резервному регіоні. Ця конфігурація може не знадобитися, якщо функція Lambda в резервній області має зарезервований паралелізм, встановлений на нуль, але може служити перевіркою безпеки, щоб уникнути нескінченного циклу реплікації даних. Для цієї публікації ми створюємо глобальну таблицю під назвою
kdsActiveRegionConfig
і помістіть елемент із такими даними:{ "stream-name": "example-stream-1", "active-region" : "us-east-1" }
- Потоки даних Kinesis – Потік, для якого процесор CDC створює дані. Для цієї публікації ми використовуємо потік під назвою
example-stream-1
в обох Регіонах з однаковою конфігурацією сегментів і політиками доступу.
Послідовність кроків міжрегіональної реплікації
Давайте коротко розглянемо, як реалізується архітектура за допомогою наступної діаграми послідовності.
Послідовність складається з наступних кроків:
- Процесор CDC (в
us-east-1
) читає дані CDC із віддаленого джерела даних. - Процесор CDC (в
us-east-1
) передає дані CDC до Kinesis Data Streams (inus-east-1
). - Лямбда-функція міжрегіональної реплікації (у us-east-1) споживає дані з потоку даних (у
us-east-1
). Розширений шаблон розгортання рекомендовано для виділеної та підвищеної пропускної здатності для реплікації між регіонами. - Лямбда-функція реплікатора (в
us-east-1
) перевіряє свій поточний регіон за допомогою активної конфігурації регіону для потоку, що споживається, за допомогоюkdsActiveRegionConfig
Глобальна таблиця DynamoDB. Наступний приклад коду (на Java) може допомогти проілюструвати умову, що оцінюється:// Fetch the current AWS Region from the Lambda function’s environment String currentAWSRegion = System.getenv(“AWS_REGION”); // Read the stream name from the first Kinesis Record once for the entire batch being processed. This is done because we are reusing the same Lambda function for replicating multiple streams. String currentStreamNameConsumed = kinesisRecord.getEventSourceARN().split(“:”)[5].split(“/”)[1]; // Build the DynamoDB query condition using the stream name Map<String, Condition> keyConditions = singletonMap(“streamName”, Condition.builder().comparisonOperator(EQ).attributeValueList(AttributeValue.builder().s(currentStreamNameConsumed).build()).build()); // Query the DynamoDB Global Table QueryResponse queryResponse = ddbClient.query(QueryRequest.builder().tableName("kdsActiveRegionConfig").keyConditions(keyConditions).attributesToGet(“ActiveRegion”).build());
- Функція оцінює відповідь від DynamoDB за допомогою такого коду:
// Evaluate the response if (queryResponse.hasItems()) { AttributeValue activeRegionForStream = queryResponse.items().get(0).get(“ActiveRegion”); return currentAWSRegion.equalsIgnoreCase(activeRegionForStream.s()); }
- Залежно від відповіді функція виконує такі дії:
- Якщо відповідь є
true
, функція реплікатора створює записи для потоків даних Kinesisus-east-2
в послідовному порядку.- Якщо сталася помилка, порядковий номер запису відстежується, а ітерація порушується. Функція повертає список невдалих порядкових номерів. Повертаючи невдалий порядковий номер, рішення використовує функцію Лямбда контрольно-пропускний пункт мати можливість відновити обробку пакета записів із частковими збоями. Це корисно під час обробки будь-яких порушень служби, коли функція намагається відтворити дані між регіонами, щоб забезпечити парність потоку та відсутність втрати даних.
- Якщо помилок немає, повертається порожній список, який вказує на те, що пакет був успішним.
- Якщо відповідь є
false
, функція реплікатора повертається без виконання реплікації. Щоб зменшити вартість викликів Lambda, ви можете встановити зарезервований паралелізм функції в регіоні DR (us-east-2
) до нуля. Це запобіжить виклику функції. Під час відновлення після відмови ви можете оновити це значення до відповідного числа на основі пропускної здатності CDC і встановити зарезервований паралелізм функції вus-east-1
до нуля, щоб запобігти непотрібному виконанню.
- Якщо відповідь є
- Після того, як усі записи будуть створені для Kinesis Data Streams
us-east-2
, контрольні точки функції реплікатораkdsReplicationCheckpoint
Глобальна таблиця DynamoDB (вus-east-1
) з такими даними:{ "streamName": "example-stream-1", "lastReplicatedTimestamp": "2022-07-18T20:00:00" }
- Функція повертається після успішної обробки пакета записів.
Міркування щодо продуктивності
Очікувану ефективність рішення слід розуміти з урахуванням таких факторів:
- Вибір регіону – Затримка реплікації прямо пропорційна відстані, яку долають дані, тому зрозумійте вибір регіону
- Швидкість – Швидкість надходження даних або обсяг даних, що копіюються
- Розмір корисного навантаження – Розмір корисного навантаження, що копіюється
Відстежуйте реплікацію між регіонами
Рекомендується відстежувати реплікацію та спостерігати за нею. Ви можете налаштувати функцію Lambda для публікації спеціальних показників у CloudWatch із зазначеними нижче показниками в кінці кожного виклику. Публікація цих показників як у первинному, так і в вторинному регіонах допомагає захистити вас від погіршень, що впливають на спостережуваність у первинному регіоні.
- Пропускна здатність – Поточний розмір пакета виклику Lambda
- ReplicationLagSeconds – Різниця між поточною міткою часу (після обробки всіх записів) і
ApproximateArrivalTimestamp
останнього запису, який було відтворено
Наступний приклад графіка показників CloudWatch показує, що середня затримка реплікації становила 2 секунди з пропускною здатністю 100 записів, реплікованих із us-east-1
до us-east-2
.
Загальна стратегія відновлення після відмови
Під час будь-яких порушень, що впливають на конвеєр CDC у первинному регіоні, потреби забезпечення безперервності роботи або аварійного відновлення можуть диктувати перемикання конвеєра після відмови до вторинного (резервного) регіону. Це означає, що в процесі відновлення після відмови потрібно виконати кілька речей:
- Якщо можливо, зупиніть усі завдання CDC у інструменті процесора CDC
us-east-1
. - Процесор CDC має бути переведений на вторинний регіон, щоб він міг зчитувати дані CDC із віддаленого джерела даних під час роботи з резервного регіону.
- Команда
kdsActiveRegionConfig
Глобальну таблицю DynamoDB потрібно оновити. Наприклад, для потокуexample-stream-1
використовується в нашому прикладі, активний регіон змінено наus-east-2
:
{ "stream-name": "example-stream-1", "active-Region" : "us-east-2"
}
- Усі контрольні точки потоку потрібно зчитувати з
kdsReplicationCheckpoint
Глобальна таблиця DynamoDB (вus-east-2
), і мітки часу з кожної з контрольних точок використовуються для запуску завдань CDC в інструменті виробника вus-east-2
Регіон. Це мінімізує ймовірність втрати даних і точно відновлює потокове передавання даних CDC із віддаленого джерела даних, починаючи з часової позначки контрольної точки. - Якщо для керування лямбда-викликами використовується зарезервований паралелізм, установіть нульове значення в основному регіоні (
us-east-1
) і до відповідного ненульового значення у вторинній області (us-east-2
).
Багатоетапна стратегія відновлення після відмови Vanguard
Деякі інструменти сторонніх розробників, які використовує Vanguard, мають двоетапний процес CDC потокової передачі даних із віддаленого джерела даних до місця призначення. Вибраний інструмент Vanguard для процесора CDC використовує цей двоетапний підхід:
- Перший крок передбачає налаштування потокового завдання журналу, яке зчитує дані з віддаленого джерела даних і зберігається в проміжному місці.
- Другий крок передбачає налаштування індивідуальних завдань споживача, які зчитують дані з місця розміщення, яке може бути ввімкнено Еластична файлова система Amazon (Amazon EFS) або Amazon FSx, наприклад, і передайте його до пункту призначення. Гнучкість тут полягає в тому, що кожне з цих завдань споживача може бути запущено для потокової передачі з різних часових позначок фіксації. Завдання потоку журналу зазвичай починає зчитувати дані з мінімуму всіх позначок часу фіксації, які використовуються завданнями споживача.
Давайте розглянемо приклад, щоб пояснити сценарій:
- Завдання споживача A передає дані з мітки часу фіксації 2022-07-19T20:00:00 і далі до
example-stream-1
. - Завдання споживача B передає дані з мітки часу фіксації 2022-07-19T21:00:00 і далі до
example-stream-2
. - У цій ситуації потік журналу має зчитувати дані з віддаленого джерела даних із мінімальних позначок часу, які використовуються завданнями споживача, тобто 2022-07-19T20:00:00.
Наступна діаграма послідовності демонструє точні кроки, які потрібно виконати під час відновлення після відмови us-east-2
(Регіон очікування).
Ці кроки є наступними:
- Процес відновлення після відмови запускається в резервному регіоні (
us-east-2
у цьому прикладі), коли потрібно. Зауважте, що тригер можна автоматизувати за допомогою комплексних перевірок працездатності конвеєра в основному регіоні. - Процес відновлення після відмови оновлює глобальну таблицю kdsActiveRegionConfig DynamoDB новим значенням для регіону як
us-east-2
для всіх назв потоків. - Наступним кроком є отримання всіх контрольних точок потоку з
kdsReplicationCheckpoint
Глобальна таблиця DynamoDB (вus-east-2
). - Після зчитування інформації про контрольну точку процес відновлення після відмови знаходить мінімум усіх
lastReplicatedTimestamp
. - Завдання потоку журналу в інструменті процесора CDC запускається в
us-east-2
із міткою часу, знайденою на кроці 4. Він починає читати дані CDC із віддаленого джерела даних із цієї мітки часу й зберігає їх у місці проміжки на AWS. - Наступним кроком є запуск усіх завдань споживача, щоб зчитувати дані з проміжного розташування та передати в цільовий потік даних. Тут кожне завдання споживача отримує відповідну позначку часу з
kdsReplicationCheckpoint
таблиця згідно зstreamName
до якого завдання передає дані.
Після запуску всіх завдань користувача дані створюються для потоків даних Kinesis в us-east-2. З цього моменту процес міжрегіональної реплікації такий самий, як описано раніше – лямбда-функція реплікації в us-east-2
починає копіювати дані в потік даних us-east-1
.
Очікується, що споживчі програми, які зчитують дані з потоків, будуть ідемпотентними, щоб мати можливість обробляти дублікати. Дублікати можуть бути введені в потік через багато причин, деякі з яких названі нижче.
- Виробник або процесор CDC вводить дублікати в потік під час відтворення даних CDC під час відновлення після відмови
- Глобальна таблиця DynamoDB використовує асинхронну реплікацію даних між регіонами та, якщо
kdsReplicationCheckpoint
дані таблиці мають затримку реплікації, процес відновлення після відмови потенційно може використовувати старішу позначку часу контрольної точки для повторного відтворення даних CDC.
Крім того, споживацькі програми повинні перевірити CommitTimestamp останнього використаного запису. Це робиться для кращого моніторингу та відновлення.
Шлях до зрілості: автоматичне відновлення
Ідеальним станом є повна автоматизація процесу відновлення після відмови, скорочення часу на відновлення та досягнення цільового рівня стійкості (SLO). Однак у більшості організацій рішення про відмову, повернення та ініціювання переключення вимагає ручного втручання в оцінку ситуації та прийняття рішення про результат. Створення сценаріїв автоматизації для виконання відмов, які можуть бути запущені людиною, є хорошим місцем для початку.
Vanguard автоматизував усі етапи перемикання після відмови, але люди все ще повинні приймати рішення про те, коли його активувати. Ви можете налаштувати рішення відповідно до своїх потреб і залежно від інструменту процесора CDC, який ви використовуєте у своєму середовищі.
Висновок
У цій публікації ми описали, як Vanguard впровадив інновації та створив рішення для реплікації даних між регіонами в потоках даних Kinesis, щоб зробити дані високодоступними. Ми також продемонстрували надійну стратегію контрольних точок для полегшення регіонального перемикання процесу реплікації, коли це необхідно. Рішення також продемонструвало, як використовувати глобальні таблиці DynamoDB для відстеження контрольних точок реплікації та конфігурації. Завдяки цій архітектурі Vanguard зміг розгорнути робочі навантаження залежно від даних CDC у кількох регіонах, щоб задовольнити бізнес-потреби високої доступності в умовах погіршення обслуговування, що впливає на конвеєри CDC у основному регіоні.
Якщо у вас є відгуки, залиште коментар у розділі коментарів нижче.
Про авторів
Рагу Боппанна працює архітектором підприємства в Головному технологічному офісі Vanguard. Рагу спеціалізується на аналізі даних, міграції/реплікації даних, включаючи конвеєри CDC, аварійному відновленні та базах даних. Він отримав кілька сертифікатів AWS, зокрема AWS Certified Security – спеціальність і AWS Certified Data Analytics – спеціальність.
Парамесваран V Вайдянатан є старшим архітектором хмарної стійкості Amazon Web Services. Він допомагає великим підприємствам досягати бізнес-цілей, розробляючи та створюючи масштабовані й стійкі рішення в хмарі AWS.
Річа Каул є старшим керівником відділу рішень для клієнтів, що обслуговує клієнтів служби фінансових послуг. Вона живе в Нью-Йорку. Вона має великий досвід у широкомасштабній хмарній трансформації, досконалості співробітників і цифрових рішеннях нового покоління. Вона та її команда зосереджуються на оптимізації цінності хмари шляхом створення ефективних, стійких і гнучких рішень. Річа любить різні види спорту, як-от триатлон, музику та вивчає нові технології.
Мітхіл Прасад є головним менеджером з рішень для клієнтів Amazon Web Services. У своїй ролі Мітіл працює з Клієнтами, щоб стимулювати реалізацію хмарних цінностей, забезпечувати інтелектуальне лідерство, щоб допомогти підприємствам досягти швидкості, гнучкості та інновацій.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
- джерело: https://aws.amazon.com/blogs/big-data/how-vanguard-made-their-technology-platform-resilient-and-efficient-by-building-cross-region-replication-for-amazon-kinesis-data-streams/
- 1
- 100
- 2022
- 28
- a
- здатність
- Здатний
- МЕНЮ
- вище
- доступ
- За
- рахунки
- точно
- Achieve
- через
- дії
- активний
- активно
- насправді
- доповнення
- рада
- зачіпає
- доступний
- після
- проти
- моторний
- ВСІ
- дозволяє
- альтернатива
- Amazon
- Amazon EC2
- Амазонський кінезіс
- Amazon Web Services
- суми
- аналітика
- та
- застосування
- підхід
- відповідний
- архітектура
- автоматизувати
- Автоматизований
- Автоматизація
- наявність
- доступний
- середній
- уникнути
- AWS
- Сертифікований AWS
- назад
- заснований
- оскільки
- буття
- нижче
- Краще
- між
- коротко
- Зламаний
- будувати
- Створюємо
- побудований
- вбудований
- бізнес
- забезпечення безперервності бізнесу
- підприємства
- званий
- захоплення
- захвати
- випадок
- CDC
- сертифікати
- Сертифікований
- шанси
- зміна
- перевірка
- Перевірки
- головний
- вибір
- хмара
- ХМАРНІ ТЕХНОЛОГІЇ
- код
- коментар
- коментарі
- commit
- компонент
- всеосяжний
- обчислення
- стан
- конфігурація
- міркування
- спожитий
- споживач
- Споживачі
- споживання
- постійно
- контроль
- Коштувати
- може
- Пара
- створювати
- створення
- критичний
- Поточний
- В даний час
- виготовлений на замовлення
- клієнт
- Рішення для клієнтів
- Клієнти
- налаштувати
- дані
- Analytics даних
- втрати даних
- Database
- базами даних
- Вирішивши
- рішення
- присвячених
- продемонстрований
- демонструє
- Залежно
- залежить
- розгортання
- розгорнути
- описаний
- призначення
- деталь
- різниця
- різний
- цифровий
- безпосередньо
- катастрофа
- обговорювалися
- відстань
- управляти
- водіння
- дублікати
- під час
- кожен
- Раніше
- зароблений
- економія
- Економія від масштабу
- ефективний
- Співробітник
- дозволяє
- підвищена
- забезпечувати
- підприємство
- підприємств
- Весь
- Навколишнє середовище
- Ефір (ETH)
- оцінювати
- оцінюється
- Event
- Кожен
- приклад
- Перевага
- виконання
- очікування
- очікуваний
- досвід
- Пояснювати
- Пояснює
- обширний
- зовнішній
- Особа
- фасилітувати
- фактори
- FAIL
- не вдалося
- Провал
- особливість
- зворотний зв'язок
- поле
- філе
- фінансовий
- фінансові послуги
- знахідки
- Перший
- Гнучкість
- Сфокусувати
- після
- слідує
- Для інвесторів
- знайдений
- від
- повністю
- функція
- покоління
- Глобальний
- земну кулю
- Цілі
- добре
- графік
- гість
- Guest Post
- обробляти
- Обробка
- відбувається
- здоров'я
- допомога
- допомагає
- тут
- Високий
- дуже
- Як
- How To
- Однак
- HTTPS
- людина
- Людей
- IAM
- ідеальний
- Особистість
- порушення
- удосконалювати
- поліпшується
- in
- У тому числі
- Вхідний
- збільшений
- вказує
- індивідуальний
- інформація
- Інфраструктура
- інновація
- екземпляр
- втручання
- введені
- Вводить
- інвестор
- Інвестори
- включає в себе
- IT
- ітерація
- Java
- липень
- ключ
- Потоки даних Kinesis
- великий
- останній
- Затримка
- лідер
- Керівництво
- вивчення
- Залишати
- рівень
- Лінія
- ліній
- список
- трохи
- розташування
- подивитися
- від
- made
- підтримує
- зробити
- РОБОТИ
- вдалося
- менеджер
- манера
- керівництво
- багато
- відображення
- масово
- зрілість
- засоби
- механізм
- Зустрічатися
- засідання
- метрика
- Метрика
- мінімальний
- мінімальний
- режим
- модифікований
- моніторинг
- найбільш
- багато
- множинний
- музика
- ім'я
- Імена
- рідний
- Необхідність
- необхідний
- потреби
- Нові
- Нові технології
- Нью-Йорк
- наступний
- номер
- номера
- мета
- спостерігати
- Office
- операційний
- оптимізуючий
- організації
- Результат
- паритет
- частина
- партнерська
- партія
- Викрійки
- виконувати
- продуктивність
- виконанні
- Дозволи
- зберігається
- Персоналізовані
- трубопровід
- місце
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- будь ласка
- Політика
- це можливо
- пошта
- потенційно
- запобігати
- первинний
- Головний
- процес
- обробка
- процесор
- Вироблений
- виробник
- Виробники
- сприяє
- захист
- забезпечувати
- за умови
- забезпечує
- публікувати
- Видавничий
- цілей
- put
- Читати
- читання
- реалізація
- Причини
- рекомендований
- запис
- облік
- Відновлювати
- відновлення
- зменшити
- зниження
- регіон
- регіональний
- райони
- віддалений
- тиражувати
- тиражує
- копіювання
- вимагається
- Вимога
- Вимагається
- захищені
- пружність
- пружний
- відповідь
- REST
- резюме
- повертати
- повернення
- Умови повернення
- міцний
- Роль
- Прокат
- ROW
- прогін
- Безпека
- то ж
- масштабовані
- шкала
- сценарій
- другий
- вторинний
- seconds
- розділ
- безпеку
- старший
- Послідовність
- служити
- обслуговування
- Послуги
- виступаючої
- комплект
- установка
- кілька
- Повинен
- показаний
- Шоу
- простота
- ситуація
- Розмір
- So
- рішення
- Рішення
- деякі
- Source
- Джерела
- спеціалізується
- Спеціальність
- швидкість
- SPORTS
- інсценування
- старт
- почалася
- починається
- стан
- Крок
- заходи
- Як і раніше
- Стоп
- зберігати
- Стратегія
- потік
- потоковий
- Потокове сервіс
- потоки
- успішний
- Успішно
- підходящий
- чудовий
- поставляється
- Опори
- система
- таблиця
- приймає
- Мета
- Завдання
- завдання
- команда
- команди
- технічний
- Технології
- Технологія
- Команда
- їх
- речі
- третя сторона
- думка
- думка лідерства
- через
- пропускна здатність
- час
- відмітка часу
- до
- інструмент
- інструменти
- трек
- Відстеження
- Перетворення
- поїздки
- викликати
- спрацьовує
- розуміти
- зрозуміла
- необов'язково
- Оновити
- оновлений
- Updates
- використання
- використання випадку
- зазвичай
- UTC
- значення
- авангардний
- VeloCity
- через
- обсяг
- Web
- веб-сервіси
- який
- в той час як
- волі
- в
- без
- працює
- б
- запис
- письмовий
- вашу
- себе
- зефірнет
- нуль
- зони