Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg — в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров — Go.

Что такое вообще объектные хранилища?

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

Объектом может быть что угодно: изображение, видео или текстовый документ. Помимо идентификатора метаданные также содержат дополнительную информацию об объекте, такую как: дата создания, тип файла, автор и другие атрибуты, почти не сказывающиеся на самих свойствах объекта, в отличие от аналогичных в файловой системе (например, тот же автор), почти не сказывающиеся.

Отличие объектных хранилищ от традиционных файловых систем

Привычные файловые системы NTFS, EXT4 и т.д. организуют файлы в виде иерархической структуры папок. Такая модель хорошо работает для небольших объемов данных и простых сценариев использования, когда количество файлов относительно невелико, к примеру, на личном устройстве или домашнем файловом сервере. Но, когда объём данных начинает переваливать за терабайты, а количество пользователей — это не несколько членов вашей семьи, подключающихся по WiFi к NAS, чтобы посмотреть вечером кино, пролистнуть фотки или скачать сканы загранпаспортов, уже начинаются заметные трудности по скорости работы и затрате ресурсов на выполнение операций.

Без жёсткой иерархической структуры все операции к доступу данных сводятся просто к использованию ключа для поиска нужного объекта: никаких долгих поисков по подпапкам подпапок и проверок прав доступа. К тому же, когда основное требование к объекту — это его уникальный идентификатор, система легко масштабируется: просто докидывайте объекты, пока хватает места на накопителе. А если не хватает, то расширьте на лету — капризов, как с файловыми системами, которые потребуют зачастую для подобного финта ушами форматирование или хотя бы отмонтировать раздел — не возникает. 

Особенности объектных хранилищ

Из преимуществ можно отметить:

Масштабируемость. Как уже было ранее упомянуто, легко масштабируются горизонтально путем добавления новых узлов и увеличения емкости хранилища. Только поспевайте подносить новые диски или стойки с СХД в серверную комнату.

Гибкость. В объектных хранилищах можно хранить любые типы данных: от небольших текстовых файлов до крупных видеороликов с тем, как 24 часа режут ножницами воду из-под крана. Всё в равной мере легко и просто контролируется через API.

Простота управления. Никаких заморочек с иерархией. Папки, подпапки, автор, права доступа, настраиваемые через chmod, — это всё не про объектные хранилища. Метаданные хранятся вместе с объектами, что позволяет их легко и быстро индексировать.

Надежность и доступность. Объектные хранилища достаточно просто децентрализовать на физически удалённых устройствах, где данные реплицируются на нескольких узлах, составляя при этом единую систему. Это гарантирует высокую надежность и доступность даже в случае отказа одного или нескольких узлов.

Но есть у объектных хранилищ и недостатки — там, где требуется максимально быстрое выполнение операций или работа с большим количеством маленьких файлов, лучше присмотреться к блочным хранилищам.
Кроме того, объектные хранилища по определению не подходят для работы с данными, где нужна строгая иерархия, различные права доступа, ссылки и т.п. Что, впрочем, никого не останавливает забивать гвозди микроскопом и превращать объектные хранилища в файловые системы. Зачем — история умалчивает.

Применение объектных хранилищ

Объектные хранилища широко используются в различных облачных сервисах и платформах, где зачастую требуется хранение и совершение операций с большим объёмом информации:

Резервное копирование и архивирование. Объектные хранилища идеально подходят для долгосрочного хранения данных, например, для резервных копий и архивов. Особенно, когда бэкапов много, и их нужно сделать и забыть до следующего обвала системы.

Хранение медиафайлов. Если вам требуется создать файлопомойку для вашего онлайн-кинотеатра, куда вы просто хотите скидывать все файлы, не заморачиваясь, объектные хранилища — ваш друг.

Облачные приложения. Облачные сервисы и приложения по модели SaaS или PaaS зачастую используют объектные хранилища для хранения пользовательских данных, логов, отчетов и других неупорядоченных данных, которые, как правило, будут лежать бесхозно до второго пришествия.

Контейнеры и микросервисы. В контейнеризованных средах микросервисов объектные хранилища используются для хранения и передачи данных между различными сервисами, обеспечивая переносимость и децентрализованность архитектуры системы.

Что такое S3?

С основами мы разобрались, а теперь поговорим о S3 — сервисе, протоколе и технологии, который, по сути, стал синонимичным для словосочетания “объектные хранилища”.

S3 предлагает пользователям простой и масштабируемый способ хранения данных через веб-интерфейс. Он поддерживает различные протоколы доступа, включая REST API, и интегрируется с другими сервисами AWS, такими как: EC2, Lambda и RDS. Благодаря своей надежности, доступности и гибкости, S3 стал стандартом де-факто для облачного хранения данных.

Интересно отметить, что, появившись 14 марта 2006 года, S3 в итоге стал не просто очередным сервисом от AWS, а эталоном для всех объектных хранилищ. Это привело к тому, что многие компании и разработчики начали создавать свои решения совместимые с S3 API, чтобы обеспечить пользователям возможность использовать те же инструменты и приложения, что и с S3, но на других платформах.

Как S3, но не S3

Когда мы говорим "S3", то чаще всего подразумевается не сервис от AWS. S3 постепенно превратилось в то, чем стал "ксерокс" для сканеров или "гугл" для поисковых систем — именем нарицательным. Термин "S3" стал обозначать целый класс объектных хранилищ совместимых с оригинальным стандартом API от Amazon.

Причина тому простая: S3 появился достаточно давно, уже 18 лет прошло, то есть сыграл эффект первопроходца. И ко всему прочему первопроходец в лице Amazon: мало того, что это одна из самых богатых мегакорпораций, так она и на облачном рынке без устали претендует на то, чтобы поджать весь рынок под себя. Из плюсов для простых смертных —API S3 оказался крайне простым и понятным в освоении, что способствовало его широкой адаптации. В результате S3 API превратился в своего рода универсальный язык для взаимодействия с объектными хранилищами.

Однако по сравнению с "ксероксом", где термин просто стал синонимом любого сканера, в случае с S3 — ситуация посложнее. S3-совместимые хранилища следуют общему стандарту. Они реализуют тот же API, что и оригинал от Amazon. То есть, будучи знакомым с оригиналом в экосистеме AWS, вы сможет с легкостью работать и с любыми другими S3-совместимыми хранилищами, будь-то Ceph, MinIO и т.п.

В результате эта стандартизация объектных хранилищ по лекалу S3 привела к интересному эффекту на рынке. Компании, не желавшие полностью зависеть от Amazon, чего, кажется, не хочет даже сама Amazon, или ищущие более экономичные альтернативы, чего также, кажется, хочет и сама Amazon, начали разрабатывать свои собственные объектные хранилища совместимые с S3, но которые просто называют S3-хранилищами. Хотя, если бы речь была не о IT, а о пищевых продуктах, то такую историю бы назвали скорее S3-продукт идентичный натуральному, либо S3-продукт имитация. Это, как если бы производители сканеров не просто назывались "ксероксами", а в значительной мере опирались на документацию и стандарты, используемые в оригиналах от самой Xerox.

Ceph, например, через свой RADOS Gateway (RGW) так хорошо имитирует S3, что большая часть приложений, изначально заточенных для AWS, может спокойно работать с Ceph, как с родным. MinIO пошел еще дальше и сделал совместимость с S3 API своим основным преимуществом, делая миграцию из AWS на собственное self-host решение или к провайдеру, использующим MinIO для S3-хранилищ ещё более бесшовным.

Но стоит понимать, что пусть все эти имитации и используют общий API и стандарт S3, они могут серьёзно различаться в своём бэкенде. Ceph и MinIO — это две совершенно разные истории, с как минимум различной производительностью и уровнем потребления ресурсов.

Рубрика Эээксперименты

Теория — это, конечно, здорово, но давайте перейдем к практике и попробуем написать своё объектное хранилище на Go. Почему? А почему бы и да?

Шаг 1: Создание и настройка проекта

Начнем с основ. Создадим директорию для нашего проекта и инициализируем Go-модуль:

```bash
mkdir go-object-storage
cd go-object-storage
go mod init go-object-storage
```

Шаг 2: Написание кода

Теперь самое интересное. Создадим файл main.go и приступаем к написанию кода:

Архитектура приложения

Наше приложение представляет собой простое объектное хранилище. Давайте разберем его ключевые компоненты:

1 — Структура Storage:

```
type Storage struct {
    mu    sync.Mutex
    files map[string][]byte
}
```

Это ядро нашего хранилища. Оно использует хэш-таблицу (map) для хранения объектов в памяти, где ключ — это имя файла, а значение — его содержимое в виде байтов. Мьютекс (sync.Mutex) обеспечивает потокобезопасность при одновременном доступе.

2 — Методы Save и Load:

```go
func (s *Storage) Save(key string, data []byte)
func (s *Storage) Load(key string) ([]byte, bool)
```

Эти методы отвечают за сохранение и загрузку объектов. Save сохраняет данные как в оперативной памяти, так и на файловой системе, обеспечивая персистентность данных. Load загружает данные сначала из памяти, а при отсутствии данных там — с диска.

• В текущей версии приложение сохраняет данные на диск, но при перезапуске сервера они не загружаются назад в память. Так что это лишь заготовка для реализации на будущее.

3 — HTTP-обработчики:

```go
func HandleUpload(w http.ResponseWriter, r *http.Request, storage *Storage)
func HandleDownload(w http.ResponseWriter, r *http.Request, storage *Storage)
func HandleList(w http.ResponseWriter, r *http.Request, storage *Storage)
```

Эти функции обрабатывают HTTP-запросы для загрузки, скачивания и листинга объектов:

• HandleUpload загружает данные на сервер и сохраняет их в хранилище.

• HandleDownload предоставляет клиенту данные из хранилища по запросу.

• HandleList возвращает список всех объектов, хранящихся в системе.

4 — Функция main:

```go

func main() {...}
```

Инициализирует хранилище и запускает HTTP-сервер.

Само приложение

```go
package main

import (
	"encoding/json"
	"fmt"
	"io/ioutil"
	"log"
	"net/http"
	"os"
	"sync"
)

const (
	STORAGE_DIR         = "./storage"        // ДИРЕКТОРИЯ ДЛЯ ХРАНЕНИЯ ОБЪЕКТОВ
	UPLOAD_PREFIX_LEN   = len("/upload/")    // ДЛИНА ПРЕФИКСА ДЛЯ МАРШРУТА ЗАГРУЗКИ
	DOWNLOAD_PREFIX_LEN = len("/download/")  // ДЛИНА ПРЕФИКСА ДЛЯ МАРШРУТА ЗАГРУЗКИ
)

// Storage — структура для хранения объектов в памяти
type Storage struct {
	mu    sync.Mutex            // Мьютекс для обеспечения потокобезопасности
	files map[string][]byte      // Хэш-таблица для хранения данных объектов
}

// NewStorage — конструктор для создания нового хранилища
func NewStorage() *Storage {
	return &Storage{
		files: make(map[string][]byte),
	}
}

// Save — метод для сохранения объекта в хранилище
func (s *Storage) Save(key string, data []byte) {
	s.mu.Lock()         // Захватываем мьютекс перед записью
	defer s.mu.Unlock() // Освобождаем мьютекс после записи

	// Сохраняем данные в памяти
	s.files[key] = data

	// Также сохраняем данные на диск
	err := ioutil.WriteFile(STORAGE_DIR+"/"+key, data, 0644)
	if err != nil {
		log.Printf("Ошибка при сохранении файла %s: %v", key, err)
	}
}

// Load — метод для загрузки объекта из хранилища
func (s *Storage) Load(key string) ([]byte, bool) {
	s.mu.Lock()         // Захватываем мьютекс перед чтением
	defer s.mu.Unlock() // Освобождаем мьютекс после чтения

	// Проверяем наличие объекта в памяти
	data, exists := s.files[key]
	if exists {
		return data, true
	}

	// Если объект не найден в памяти, пытаемся загрузить его с диска
	data, err := ioutil.ReadFile(STORAGE_DIR + "/" + key)
	if err != nil {
		return nil, false
	}

	// Если загрузка с диска успешна, кэшируем объект в памяти
	s.files[key] = data
	return data, true
}

// HandleUpload — обработчик для загрузки объектов
func HandleUpload(w http.ResponseWriter, r *http.Request, storage *Storage) {
	if r.Method != http.MethodPost {
		http.Error(w, "Метод не поддерживается", http.StatusMethodNotAllowed)
		return
	}

	// Получаем ключ (имя объекта) из URL
	key := r.URL.Path[UPLOAD_PREFIX_LEN:]

	// Читаем тело запроса (данные объекта)
	data, err := ioutil.ReadAll(r.Body)
	if err != nil {
		http.Error(w, "Ошибка чтения данных", http.StatusInternalServerError)
		return
	}

	// Сохраняем объект в хранилище
	storage.Save(key, data)

	// Отправляем ответ клиенту
	w.WriteHeader(http.StatusOK)
	fmt.Fprintf(w, "Объект %s успешно сохранен", key)
}

// HandleDownload — обработчик для загрузки объектов
func HandleDownload(w http.ResponseWriter, r *http.Request, storage *Storage) {
	if r.Method != http.MethodGet {
		http.Error(w, "Метод не поддерживается", http.StatusMethodNotAllowed)
		return
	}

	// Получаем ключ (имя объекта) из URL
	key := r.URL.Path[DOWNLOAD_PREFIX_LEN:]

	// Загружаем объект из хранилища
	data, exists := storage.Load(key)
	if !exists {
		http.Error(w, "Объект не найден", http.StatusNotFound)
		return
	}

	// Отправляем данные объекта клиенту
	w.WriteHeader(http.StatusOK)
	w.Write(data)
}

// HandleList — обработчик для вывода списка всех объектов
func HandleList(w http.ResponseWriter, r *http.Request, storage *Storage) {
	if r.Method != http.MethodGet {
		http.Error(w, "Метод не поддерживается", http.StatusMethodNotAllowed)
		return
	}

	// Захватываем мьютекс для доступа к хэш-таблице объектов
	storage.mu.Lock()
	defer storage.mu.Unlock()

	// Создаем список ключей (имен объектов)
	keys := make([]string, 0, len(storage.files))
	for key := range storage.files {
		keys = append(keys, key)
	}

	// Кодируем список ключей в формат JSON и отправляем клиенту
	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(keys)
}

func main() {
	// Проверяем наличие директории для хранения объектов
	if _, err := os.Stat(STORAGE_DIR); os.IsNotExist(err) {
		err := os.Mkdir(STORAGE_DIR, 0755)
		if err != nil {
			log.Fatalf("Ошибка создания директории %s: %v", STORAGE_DIR, err)
		}
	}

	// Создаем новое хранилище
	storage := NewStorage()

	// Настраиваем маршруты для обработки HTTP-запросов
	http.HandleFunc("/upload/", func(w http.ResponseWriter, r *http.Request) {
		HandleUpload(w, r, storage)
	})
	http.HandleFunc("/download/", func(w http.ResponseWriter, r *http.Request) {
		HandleDownload(w, r, storage)
	})
	http.HandleFunc("/list", func(w http.ResponseWriter, r *http.Request) {
		HandleList(w, r, storage)
	})

	// Запускаем HTTP-сервер на порту 8080
	log.Println("Сервер запущен на порту 8080")
	log.Fatal(http.ListenAndServe(":8080", nil))
}
```

Компилируем и тестируем

Теперь скомпилируем наше приложение:

```bash
go build -o object-storage
```

И запустим наш свежеиспечённый сервер:

```bash
./object-storage
```

Давайте проверим, как работает наше творение. Используем curl для тестирования:

1. Загрузка объекта:

```bash
curl -X POST -d "Hello, World!" http://localhost:8080/upload/hello.txt
```

2. Скачивание объекта:

```bash
curl -O http://localhost:8080/download/hello.txt
```

3. Получение списка всех объектов:

```bash
curl http://localhost:8080/list
```

Вуаля! Мы создали простое объектное хранилище на Go. Конечно, это лишь базовая реализация, и в реальном мире вам понадобится гораздо больше дополнительного функционала поверх. Но это достаточно хорошая отправная точка для дальнейших экспериментов и изучения объектных хранилищ в рамках пэт-проекта.

P.S. Как можно заметить, в проекте активно используется файловая система Linux, хотя ранее весь пост я распинался про то, как объектные хранилища отличаются от файловых систем и вообще «Это другое»(тм). Всё дело в том, что здесь есть нюанс. То была теория, а на практике, объектные хранилища — это *барабанная дробь* – абстракция. Да, не опять, а снова. И если заглянуть в их суть, основу и базу, на нулевом уровне они будут использовать файловые системы для хранения информации.

Итог

История S3 и объектных-хранилищ в целом наглядно показывает старую и регулярно повторяющуюся историю, как технология за счёт возникновения в нужное время и в нужной компании, за счёт эффекта первопроходца и вкупе с монструозными размерами рынка, становится отраслевым стандартом и именем нарицательным для своих сородичей по цеху.
Впрочем, это было бы принижением достижений S3. Успех как сервиса, так и стандарта в значительной мере был также обеспечен простотой и понятной API и экосистемы в целом, что позволило легко и быстро даже новичками на лету интегрировать его в инфраструктуру своих сервисов и приложений. В итоге и без того укрепив позиции S3, как де-факто стандарта облачных хранилищ.

В cdnnow!, как можно догадаться после прочтения этой статьи, мы предоставляем клиентам доступ к различным хранилищам, включая S3-совместимые, на основе нашей реализации с помощью Ceph. Это позволяет гибко управлять данными, используя знакомые инструменты и процессы. А также не бояться, что из-за очередного пакета санкций придётся сказать “пока” вашему S3 хранилищу в рамках экосистемы AWS.