Architecture of infrastructure in cloud 0.5

2,773 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,773
On SlideShare
0
From Embeds
0
Number of Embeds
84
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • С каждым днем количество пользователей в сети растет, если средний сайт раньше должен был работать с 10ми и сотнями пользователями онлайн, теперь эта уже как минимум тысячи.Все чаще проекту нужно быстро, а желательно еще и автоматически справляться с растущей нагрузкой на ваше приложение.Давайте посмотрим как идет эволюция большинства проектов.
  • В самом простом случае, у нас есть application-сервер который доступен из Интернета, который обрабатывает запросы пользователей, а также отдает медиа контент (картинки, видео, CSS, JS и т.д.).На бэкенде работает сервер баз данных.Это простая схему, среднее приложение так и работает, но если оно активно развивается, количество пользователей растет, инфраструктура соответственно становится сложнее…Дальше поняли что отделение статических данных от контроллера это хорошо, т.к. уменьшается время на обработку «ненужных» запросов к апп-серверу, трафик и TCP-соединенияДальше база перестала выдерживать нагрузки и мы поставили предварительный кэш на чтение (memcached, redis, EHCache/Terracota etc.)Дальше начали плодить app-сервера т.к. CPU одного сервера не справляется с нагрузкойДальше база начала валится на записи и пришлось делать database clusterИтак мы очевидно сталкиваемся с проблемами масштабирования, а именно…
  • CPU,решается балансировкой на несколько серверовRAM, …
  • Из-за того что узкие места могут появляться в любой момент, более того для некоторых приложений это нормальная практика, вам нужно реагировать на них быстро и желательно без потерь для пользователя.Классический хостинг явно проигрывает клаудам, он не дает вам нужно быстроты в управлени и пластичности. Он не дает приложению возможности САМОМТОЯТЕЛЬНО масштабироваться.Давайте рассмотрим как должно выглядеть идеальное облачное приложение.
  • Можно выделить две основные архитектуры при построении облачных приложений…
  • Grid, решающяя задачи на вычисление или обработку данных. Научные системы, биллинг системы, обработка медиа информации (кодирование звука, видео, изображения)
  • Transactional – сделал запрос, получил ответ. Поисковые системы, блоги, соц сети и т.д.Ваше приложение масштабируется в нужных пределах по всем узким местам (CPU, сеть и т.д.)Вы используете сервисы и API облака для масштабирования в обоих направлениях (как на увеличение так и на уменьшение)
  • Облако нам дает:Снижение стоимости за счет оплаты только тех сервисов и ресурсов которые вы использовали…
  • Есть причины по которым облако не даст вам преимуществ или вы и вовсе не сможете его использовать:…
  • You can always come to us and ask questions, but we recommend you to use our Informational Portal first, it has answers to all Frequently Asked questions, integration with Management Console, Comprehensive help materials, Glossary and other valuable additions that will help you on your way to Self-Service model utilization.
  • Architecture of infrastructure in cloud 0.5

    1. 1. ARCHITECTURE OFINFRASTRUCTUREIN CLOUD 1
    2. 2. PRESENTATION STRUCTURE• Why cloud?• Cloud ready architectures• Cloud services• Disaster recovery• Capacity planning 2
    3. 3. WHY CLOUD? 3
    4. 4. WHY WE TALK ABOUT CLOUDS?• Основная причина – борьба с высокими нагрузками 4
    5. 5. CLASSICAL APPLICATION EVOLUTION Database cache User requests Database server Application server Media content Content server 5
    6. 6. KEY BOTTLENECKS• CPU -> Balancer for app servers, database clustering• RAM -> Clustering or memory consuming components• Network ing-> DNS RR, object storage, CDN• Disk I/O -> database clustering• Ping -> CDN, per-region architecture 6
    7. 7. VIRTUAL/HARDWARE VS CLOUD Virtual/HW hosting CloudOn-demand self-serviceBroad network accessResource poolingRapid elasticity 7
    8. 8. CLOUD READYARCHITECTURE 8
    9. 9. CLOUD ARCHITECTURES - GRID 9
    10. 10. CLOUD ARCHITECTURES - TRANSACTIONAL 10
    11. 11. CLOUDSERVICES 11
    12. 12. CLOUD SERVICES• Object Storage• Compute Instances• Load balancers• CDN• Networking 12
    13. 13. OBJECT STORAGE• Amazon S3• Atmos 13
    14. 14. COMPUTE INSTANCE• Amazon EC2 14
    15. 15. EPHEMERAL• Sometimes you have no “physical “ access to VM at all 15
    16. 16. LOAD BALANCERS• What is it?• How it works?• How it configures? 16
    17. 17. MONITORING• Cloud Watch• What is it?• How I can use it?• Monitoring + Load balancer 17
    18. 18. CONTENT DELIVERY NETWORK• Amazon Cloud Front• Akamai• Etc.• What is it?• Why I should use it?• Where I can use it? 18
    19. 19. NETWORKING• Public networks• Private networks• Network configuration• Security groups 19
    20. 20. DISASTERRECOVERY 20
    21. 21. AUTOMATION 21
    22. 22. MONITORING 22
    23. 23. DISASTER-READY ARCHITECTURE 23
    24. 24. CAPACITYPLANNING 24
    25. 25. DYNAMIC SCALING 25
    26. 26. PRO-ACTIVE SCALING 26
    27. 27. REACTIVE SCALING 27
    28. 28. WHY PROJECTS MOVING TO CLOUD?• Cost reduction• Pay as you go• Scalability and elasticity• Ready for automation• Device and location independent• Buzzword 28
    29. 29. WHEN YOU CANT USE CLOUD?• When you need hardware• When you need high speed I/O (high speed storage)• 100% capacity usage• Barrier to exit (migration to cloud more expensive then classical infrastructure)• Integration with legacy systems• Security concerns 29
    30. 30. OUR CONTACTS SpecialEPM-CITConsulting@epam.com http://cloud.epam.com https://twitter.com/EPAM_Cloud http://epamcloud.blogspot.com/ https://www.yammer.com/epam.com/ 30
    31. 31. QUESTIONS 31
    32. 32. THANK YOU 32

    ×