Couchbase — это документо-ориентированная база данных (не путать с CouchDB и Membase!), интересная своей относительной простотой, исключительной легкостью в настройке и поддержке, высокой скоростью выполнения запросов за счет размещения «горячих» данных в памяти, масштабируемостью, а также автоматическим восстановлением кластера в случае падения машин и рядом других моментов. Например, поддержкой вторичных индексов, вьюх, репликации между дата-центрами (XDCR, как master-slave, так и master-master), обратной совместимостью с Memcached и не только. Написано все это на С/C++ и Erlang. Couchbase используется в AOL, Cisco, LinkedIn и множестве других компаний.
Клиенты нередко приходят в наш сервер сайд или вебчик через какие-то прокси, Nginx, HAProxy, Elastic Load Balancer и другие. Прокси эти очень полезны, так как обеспечивают сжатие и шифрование трафика, балансировку нагрузки и так далее. Проблема однако заключается в том, что прокси скрывают настоящий IP пользователя, из-за чего становится невозможно определить, например, из какой страны он пришел, и соответственно, интерфейс на каком языке ему отобразить. В случае с HTTP эта проблема давно решена путем проставления заголовков с IP пользователя. Но что делать при использовании других протоколов, вебсокетов там или просто чего-то самописного поверх TCP? Вот для решения именно этой проблемы разработчиками HAProxy и был придуман proxy protocol.
ElastiCache — один из множества сервисов в Amazon, который дает облачные Memcached и Redis. Дает не просто так, а с автоматической заменой упавших нод, а также со специальным клиентом, который определяет состав созданного кластера и ходит на различные его узлы в зависимости от значения ключа. То есть, получается что-то вроде EC2 инстансов с поднятым Memcached или Redis на них в автоскейлинг группе за ELB, только с шардированием и уже готовое. В этой заметке мы научимся настраивать Amazon ElastiCache и ходить в него из кода на языке Scala.
В современном вебе, да и не только вебе, мы вынуждены создавать приложения, масштабируемые горизонтально. Как строятся такие решения всем давно хорошо известно. Чаще всего берется куча серверов, на которых разворачивается непосредственно приложение, притом все свое состояние оно держит не локально, а в каких-то СУБД. Перед этими серверами ставится балансировщик нагрузки в виде еще нескольких серверов с Nginx или HAProxy. Пользователи же направляются на балансировщик при помощи DNS. Но поддерживать все это хозяйство довольно хлопотно. И тут нам на помощь приходит Amazon!
Несмотря на существование большого количества распределенных файловых систем (Riak CS, MongoDB GridFS, Cassandra File System, и прочих) многие продолжают отдавать свое предпочтение сервису Amazon S3. Что не удивительно, учитывая его гибкость, разумную стоимость, отсутствие необходимости самому что-либо администрировать и наличие могучего SDK. В этой заметке будет показано, как работать с Amazon S3 при помощи этого SDK на языке программирования Scala.
Когда я начинал работать с Amazon Web Services (AWS), самой большой проблемой для меня было не запутаться во всех этих EC2, S3, RDS, SQS и прочих странных непонятных названиях. В данной заметке вы найдете краткий перечень основных терминов такого рода. Заметка предназначена для новичков и предположительно должна упростить начало работы с облаком Амазона.
Я тут на досуге игрался с DigitalOcean и провел небольшой эксперимент, результатами которого мне хотелось бы поделиться. Были взяты разные регионы, в каждом из них создавался дроплет и мерился пинг до этого дроплета. Сами результаты, а также попытки сделать из них какие-то выводы, смотрите далее.