Как мы спасали карточный процессинг с помощью Exadata

    В последние 10 лет ВТБ переживает мощный рост вычислительной нагрузки. Каждый год она увеличивалась в полтора раза, а объем учетных данных — в два. Службы поддержки очень старались, но угнаться за этими темпами было непросто: планы запросов отъезжали, дисковое пространство заканчивалось, обновления прикладного кода съедали все ресурсы. В этом посте мы расскажем, как решили проблему без больших трат на еще один IBM System p.



    В 2013 году карточный процессинг, тогда еще банка ВТБ24, размещался на одном из самых мощных серверов того времени — IBM System p. Это дополняли реплики для разной отчетности. На дополнительном оборудовании жили реплики для отчетности: еженощно обновляемая база для дневной отчетности, средства для активной реплики Oracle Active Data Guard для оперативной отчетности и БД для отчетности Центробанка, которую мы обновляли ежемесячно.



    Мы активно кастомизировали функциональность систем — большую часть прикладного кода занимали внутренние доработки. При этом данные разрастались очень стремительно. В результате план запросов по четырем базам регулярно ухудшался. Фронтальные системы работали медленно. В техническом ракурсе была еще одна сложность: OLTP-нагрузка карточных транзакций смешивалась с DWH/DSS-нагрузкой кастомизированной функциональности и отчетности.

    Стандартный выход из этого положения: докинуть ресурсов и перейти на более крутую подсистему хранения данных. Мы придумали более интересный вариант — взяли для отчетных реплик два оптимизированных для работы БД программно-аппаратных комплекса Oracle Exadata.

    Комплекс процессинга разделили на «теплую» и «горячую» зоны. «Горячая» зона никуда с IBM System p не переехала, и в ней сохранилась только ее база данных. «Теплая» зона представляла собой копию основной БД на Exadata. Здесь была вся отчетность и кастомизированная функциональность. Реплицировали данные с помощью Oracle GoldenGate.



    Провели тесты реплики на Exadata: в среднем, отчетность стала формироваться в пять раз быстрее благодаря архитектуре и фичам ПО Oracle  Exadata Storage — smartscans, storage indexes, bloom filters и т.д. Время подготовки отчетности для ЦБ сократилось в десятки раз и сейчас некоторые отчеты готовятся менее чем за 1 час.  Главное, что нужно было сделать для оптимизации запросов при переносе на Exadata — это удалить хинты, которые ранее помогали работать на старой платформе.



    Мы провели технико-экономическое обоснование, сопоставив по разным параметрам варианты с обычным расширением текущих систем и с привлечением двух комплексов Exadata.

    • Производительность. 40 тыс IOPS против 400 тыс IOPS у Exadata. Решение Oracle заточено на большие объемы данных, полное сканирование таблиц проходит гораздо быстрее.
    • Возможности кастомизации. В стандартном решении мы не можем изменить структуру объектов без изменений в продуктивной БД, это запрещено вендором. В Exadata мы можем удалить ненужные индексы, добавить необходимые и улучшить отклик системы.
    • Масштабирование. Exadata дает линейный рост производительности при сравнительно меньших затратах.
    • Формирование отчетности. Скорость формирования отчетности с комплексом Exadata увеличивается в 5 раз, а с масштабированием имеющихся систем — в 1,5.
    • Обслуживание. В инфраструктуре Oracle единая техподдержка, единая система обновлений для серверов, дисковых подсистем и сетевой инфраструктуры. При обычном масштабировании нужно работать с разными вендорами — и простоев больше, и всяких других неудобств.
    • Стоимость. Exadata здесь выигрывает.

    Поначалу уязвимым местом оказалась репликация на GoldenGate: в случае длинных транзакций на источнике она отставала. Мы решили это с помощью обновлений и переработки некоторых прикладных процессов. После этого работа с Exadata открывала нам лишь преимущества.

    Мы ввели кастомные индексы и партиционирование, что позволило увеличить производительность кастомных функций. IBM такую оптимизацию не разрешает.

    Перенос аналитической отчетности на «тёплую» зону позволил уменьшить глубину хранения исторических данных «горячей» зоны. Это сократило расходы на дорогостоящую СХД. Удалось ускорить вставку в индексы. Удаления данных посредством модуля housekeeping'а фильтровались на уровне GoldenGate, в результате на реплике имелись свежие данные и вся история;
    Exadata использует гибридное колоночное сжатие (HCC), и это существенно экономит дисковое пространство. Данные старше одного года сжимаются методом «archive low», старше одного месяца — методом «advanced compression», более новые данные для повышения скорости не сжимаем.

    Что касается апгрейда, то наиболее эффективно заменять в Exadata целые ячейки хранения (storage cell) на ячейки с более емкими дисками и производительными процессорами. Но можно использовать  внутри одной системы ячейки хранения разных версий — Oracle это разрешает.
    Отчетность карточного процессинга, реализованная на технологиях Oracle Exadata и Database, прекрасно работает до сих пор, и по такому же принципу строятся новые системы банка.
    ВТБ
    85,05
    Компания
    Поделиться публикацией

    Комментарии 16

      0
      Сейчас набегут и закричат про цену Exadata серверов. Хотя решение выглядит вполне логичным.

      Exadata кластеры очень хороши, чтобы консолидировать и хостить на ней много баз данных, с использованием RAC, Primary-Standby технологий
        –1
        Эти машинки в аналитике очень хороши за счет быстрого ввода-вывода и киллер фич вроде storage indexes и так далее.
        +1
        … и еще теснее погрузиться в любовь с Oracle, его техподдержкой и сейлами. ;)
          +2
          А как так получается, что в блоге вы описываете очень красивые вещи, мощную и дорогую инфраструктуру, а клиенту не могут простую проблему решить уже месяц (если совсем полностью, то полтора месяца прошло)? Проблема именно технического характера, которую не могут решить сотрудники отделения.
            +3
            А всем кто рассматривает ВТБ в качестве банка могу посоветовать еще раз подумать, потому что у банка отстуствует нормальный процесс оповещения клиентов о статусе решения проблем и все жалобы возвращаются в тоже самое отделение, которое точно также будет пытаться получить от тех. поддержки помощи. Никакого процесса эскалации проблем похоже нет. Сроки никого не волнуют. И поэтому смысла от всей описанной в блоге инфраструктуры никакого, на мой взгляд даже хуже стало (3 года клиентом был).
              0
              Сочувствую Вашему горю, но хочу уточнить: у клиента, про которого речь, именно с Oracle была проблема?
                –2
                Проблема была (есть) с ВТБ, но может быть именно продукты Oracle виноваты, кто знает?
                0
                Добрый день. Мы с радостью вам поможем, напишите нам, пожалуйста, более подробно о возникшей проблеме в любую соц.сеть (ниже ссылки), мы обязательно постараемся ускорить процесс её устранения.
                Приносим извинения за доставленные неудобства.
                Facebook: vk.com/vtb
                Vkontakte: www.facebook.com/vtbrussia
                  +1
                  А это у всех так. Почитайте любой корпоративный блог, что этот, что Альфа-банка, что Авито, что еще какой. Везде в блоге — стильно, модно, молодежно, аджайл, технологии, молодые улыбчивые люди по лучшим методикам в прекрасных офисах что-то проектируют.

                  А получается на выходе обычно глючное тормозное г, не удовлетворяющее потребности клиентов. Вон Альфа про свой банк для бизнеса раньше бодрые отчеты писали, а я с него обплеваться не могу, нафига мне онлайн-банк где я даже реквизиты счета узнать не могу (рублевого могу, а валютного — нет, там просто нет кнопки «показать реквизиты»).

                  Видимо вот такой вот он — крупный бизнес и кровавый энтерпрайз. Все компоненты в отдельности могут быть классными, а на выходе получается что-то такое.
                  +1

                  Подскажите, а пользователям то стало лучше от всего этого?

                    +1
                    Интересно было-бы увидеть статью в сравнении процессингов exBM и exVTB24 в один и тот же период времени, с указанием нагрузки и того как проблемы решались.
                      +1
                      Понятно, что appliance вздрючит «пэшки» на аналитических запросах, тут даже не нужно было сравнивать ничего. Но почему выбор пал на Exadata, а не, например, IBM PureData for Analytics (ex Netezza)? Сравнивали ли вы эти два решения?
                        0
                        Со стороны — может потому-что уже было решение на Oracle (как БД)?
                        0

                        Эм. А в сторону Z-серии не смотрели?

                          0
                          Там такая цена входа, что лучше не лезть. Плюс, другое ПО.
                          0
                          А вот я помню времена когда у меня был счет тогда еще в Гута-банке. После того как они стали ВТБ24 все (с точки зрения пользователя) становилось только хуже. И с поддержкой и с тем как раз за разом портили Телебанк (из-за которого Гута и была выбрана) как в плане функционала (например — способ подтверждения операций, было еще два КРОМЕ СМСок) так и в плане дизайна (зато новый дела какая то крутая студия (как бы не Артемий Лебедев)) и так далее.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое