Object Storage в WebDisk: бакет, об'єкт, ключ – і що це дає на практиці

Блог WebDisk · категорія: Хмарні обчислення · час читання: ~9 хвилин

Коротко:- Об'єктне сховище тримає дані як об'єкти в бакетах – не як блоки диска й не як дерево каталогів. Кожен об'єкт має свій ключ, а спілкуються з ним через HTTP, як з вебсторінкою.- Воно добре працює там, де файл записується один раз, а читається багато разів: резервні копії, архіви, медіа, статичні файли, спільний простір для застосунків. Диска під базу даних воно не замінить.- S3 сьогодні є фактичним стандартом спілкування з таким сховищем – ті самі інструменти (aws, s3cmd, rclone) і ті самі бібліотеки працюють у нас і в інших постачальників. >Не працюєте з терміналом? Блоки команд можна спокійно пропустити – решта статті читається й без них.

Корпоративний мережевий диск заповнюється швидше, ніж будь-хто планував. Камери відеоспостереження створюють записи, яких ніхто не переглядає, але які не можна видаляти. Застосунок працює у трьох копіях, і кожна з них має бачити ті самі файли.

Усі ці проблеми мають спільний знаменник: дані, яких багато, які зростають непередбачувано і які мають бути доступні з багатьох місць одночасно. Класичний диск у сервері дає з цим раду дедалі гірше з кожним доданим терабайтом. Об'єктне сховище виникло саме для того, щоб цей сценарій перестав бути проблемою.

У цій статті пояснюємо, чим об'єктне сховище відрізняється від диска й від мережевої папки, як розуміти три поняття, навколо яких усе крутиться (бакет, об'єкт, ключ), для чого S3 підходить насправді – а для чого ні – і як почати з ним працювати на практиці. Наприкінці описуємо, що з цього пропонуємо в WebDisk.

Чим відрізняються блокове, файлове та об'єктне сховища?

Блокове сховище – це найнижчий рівень: диск (фізичний або мережевий том) надає операційній системі сирі блоки, і лише файлова система надає їм сенсу. Перевага: найменші затримки й повна свобода модифікації – можна перезаписати будь-які 512 байтів усередині файлу. Недолік: том зазвичай прив'язаний до однієї машини.

Файлове сховище – це мережева папка (NFS, SMB): ієрархія каталогів, права доступу, блокування файлів, багато клієнтів одночасно. Проблема з'являється на масштабі – дерево з десятками мільйонів файлів стає дорогим в обслуговуванні, а файловий сервер буває вузьким місцем.

Об'єктне сховище відмовляється від ієрархії та від модифікації на місці. Файл потрапляє у сховище як об'єкт: вміст плюс метадані плюс унікальний ключ. Хочете його змінити? Записуєте об'єкт наново, цілком. Натомість отримуєте три речі, яких дві попередні моделі не дають так легко: практично лінійну масштабованість, доступ через звичайний HTTP з будь-якого місця і вбудовану надлишковість на боці кластера.

• Одиниця – Блокове: блок · Файлове: файл у каталозі · Об'єктне: об'єкт у бакеті
• Доступ – Блокове: драйвер диска · Файлове: мережевий протокол (NFS/SMB) · Об'єктне: HTTP (API S3)
• Модифікація фрагмента – Блокове: так · Файлове: так · Об'єктне: ні – запис цілого об'єкта
• Типовий клієнт – Блокове: одна машина · Файлове: багато машин у LAN · Об'єктне: будь-який застосунок в інтернеті
• Природне застосування – Блокове: база даних, операційна система · Файлове: спільні документи, домашні каталоги · Об'єктне: резервні копії, медіа, архіви, дані застосунків

Це не конкуренти, а три шари однієї й тієї самої скриньки з інструментами.

Що таке бакет, об'єкт і ключ у S3?

Бакет (дослівно «відерце») – це контейнер для об'єктів, відповідник диска або мережевої папки. Назва бакета має бути унікальною в межах платформи, бо вона стає частиною адреси. Саме на рівні бакета налаштовується більшість речей, які мають значення: хто має доступ, чи дані зашифровані, як довго вони живуть.

Об'єкт – це окрема збережена сутність: вміст файлу, його метадані (тип MIME, дата, власні заголовки) та ідентифікатор версії, якщо в бакеті увімкнено версіонування.

Ключ (key) – це повна назва об'єкта в бакеті, і саме тут криється найчастіше непорозуміння. Простір назв у S3 є пласким: каталогів немає, є один довгий рядок символів. Ключ 2026/07/faktury/FV-118.pdf не означає трьох вкладених тек, а лише одну назву, що містить скісні риски. Інструменти малюють з цього дерево для вашої зручності, запитуючи в сервера об'єкти, що починаються з певного префікса.

Наслідок цілком практичний: «перенесення каталогу» в S3 насправді є копіюванням і видаленням кожного об'єкта окремо. Варто про це пам'ятати, плануючи структуру ключів – добре спроєктований префікс (дата, клієнт, тип даних) полегшує потім і пошук, і політики доступу, і правила очищення.

Для чого підходить об'єктне сховище, а для чого ні?

Резервні копії та архів. Це сьогодні типова ціль для резервних копій – усі поважні системи резервного копіювання вміють писати просто до S3. Копія лежить поза сервером, який вона захищає, доступна через мережу і не вимагає утримання стрічкової бібліотеки. Ширше про це пишемо у статті Резервна копія в хмарі – основа сучасної IT-безпеки.

Медіа та статичні файли. Фотографії, відео, PDF-и, вкладення. Застосунку не потрібно пропускати їх через себе – він може відіслати користувача просто до сховища, знімаючи з власних серверів увесь трафік завантажень.

Статичний сайт або документація. Бакет із публічним читанням віддає HTML, CSS і зображення без жодного сервера застосунків. Рішення дешеве, стійке й практично не потребує обслуговування. Одне застереження: повний хостинг сайту – з документом індексу, сторінкою помилки й власним доменом – вимагає режиму website на боці постачальника; самого публічного читання достатньо, щоб віддавати файли, наприклад зображення й файли для завантаження.

Спільний простір для застосунків. Це сценарій, у якому об'єктне сховище справді сяє. Кілька екземплярів того самого застосунку – на віртуальних машинах або в подах Kubernetes – бачать той самий бакет і ті самі файли, без спільного тому й без роздумів, на якому вузлі опинився завантажений файл. Один пристрій чи процес закидає дані, інший їх забирає та обробляє.

Чого об'єктне сховище не замінить: диска під базу даних, файлової системи для застосунку, який модифікує файли на місці, ані сховища, що вимагає затримок порядку мікросекунд. Кожна операція – це HTTP-запит: він чудово витримує паралельність і великі об'єкти, але окремий запис ніколи не буде таким швидким, як запис на локальний NVMe. Немає також сенсу закидати до S3 мільйони крихітних файлів без плану: накладні витрати на запит можуть тоді переважити вартість самих даних.

Перший бакет: три інструменти, та сама історія

Для роботи з S3 вам потрібні три речі: адреса ендпоінта постачальника, ключ доступу (access key) і секрет (secret key). Наведені нижче приклади використовують наш публічний ендпоінт https://s3.dco.webdisk.io – в іншого постачальника підмініть адресу, і все працюватиме так само. Це, зрештою, одна з головних переваг стандарту S3: зміна постачальника не означає переписування інтеграції, про що ми писали у тексті про залежність від постачальника.

Одна річ, про яку варто знати одразу: адресу бакета можна складати двома способами – за шляхом (endpoint/bucket) або через назву хоста (bucket.endpoint). Типові налаштування клієнтів бувають різні, тому в прикладах нижче ми вказуємо адресацію за шляхом явно.

s3cmd – найпростіший старт, зручний для ручних операцій:

s3cmd --configure # access key, secret key, host: s3.dco.webdisk.io
                           # host_bucket: s3.dco.webdisk.io/%(bucket)s

s3cmd mb s3://firma-archiwum # створити бакет
s3cmd put raport.pdf s3://firma-archiwum/2026/ # завантажити файл
s3cmd ls s3://firma-archiwum/2026/ # вивести список префікса
s3cmd get s3://firma-archiwum/2026/raport.pdf # отримати
s3cmd du s3://firma-archiwum # скільки це займає

aws CLI – офіційний клієнт AWS, працює з кожним сховищем, сумісним із S3:

aws configure # access key, secret key, region: напр. us-east-1
aws configure set default.s3.addressing_style path # адресація за шляхом

# ендпоінт вказуєте разом із командою…
aws --endpoint-url https://s3.dco.webdisk.io s3 ls

# …або один раз, змінною середовища (aws CLI v2 від версії 2.13)
export AWS_ENDPOINT_URL=https://s3.dco.webdisk.io

aws s3 mb s3://firma-archiwum
aws s3 cp ./raporty s3://firma-archiwum/2026/ --recursive
aws s3api head-object --bucket firma-archiwum --key 2026/raport.pdf

rclone – найкращий для синхронізації каталогів і перенесення даних між постачальниками:

rclone config # тип: s3, provider: Ceph, ендпоінт як вище
                           # профіль Ceph сам вмикає адресацію за шляхом

# копіюй інкрементно: передається лише те, що змінилося
rclone copy /srv/dane webdisk:firma-archiwum/dane --progress

# увага: sync ВИДАЛЯЄ в цільовому місці файли, яких немає в джерелі
rclone sync /srv/dane webdisk:firma-archiwum/dane --dry-run

Правило, яке заощаджує нерви: rclone sync запускайте спершу з --dry-run і лише після перегляду списку змін – без цього перемикача.

Як контролювати доступ до бакета: політики та presigned URL

Типово бакет є приватним – його бачить лише власник ключів. Доступ відкривають свідомо, двома способами.

Політика бакета – це документ JSON, який описує, кому і що ми дозволяємо. Класичний приклад – бакет, що віддає статичні файли, з публічним читанням об'єктів і приватним записом:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PublicRead",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::moja-strona/*"
  }]
}

aws s3api put-bucket-policy --bucket moja-strona --policy file://polityka.json

Зверніть увагу на Resource із зірочкою: політика стосується об'єктів у бакеті, а не самого бакета. Заміна arn:aws:s3:::moja-strona/* на arn:aws:s3:::moja-strona – найчастіша помилка початківців: раптом нічого не працює або, ще гірше, працює забагато.

Presigned URL розв'язує іншу проблему: «хочу дати одній особі один файл, на годину, без створення для неї облікового запису». Це звичайне посилання на об'єкт із доклеєним підписом і датою закінчення дії. Хто має посилання, той завантажить файл; після спливу часу посилання стає непридатним, а сам бакет лишається приватним:

# посилання дійсне годину (3600 секунд)
aws s3 presign s3://firma-archiwum/2026/raport.pdf --expires-in 3600

Presigned URL працює і у зворотний бік – застосунок може згенерувати посилання, яке дає право завантажити файл до сховища, завдяки чому браузер користувача надсилає файл просто у сховище, оминаючи сервер застосунку. Варто лише пам'ятати, що таке посилання є секретом: хто його перехопить, той матиме доступ до об'єкта протягом усього терміну дії. Тому терміни встановлюють короткі, а посилання не надсилають каналами, яких не контролюють.

Третій механізм – тимчасові облікові дані (STS) – замінює постійні ключі перепусткою, дійсною годину і виданою на підставі корпоративного входу. Ми докладно описали його у статті про доступ до S3 корпоративним обліковим записом (STS + SSO). Окремий текст ми присвятили також варіантам шифрування даних у стані спокою (SSE-S3, SSE-KMS, SSE-C) – про них варто говорити при кожному впровадженні.

Що об'єктне сховище дає, а чого не дає?

Об'єктне сховище дає: масштабування без планування місткості наперед, доступ через HTTP з будь-якого місця, стандарт, який ви переносите між постачальниками, оплату за викуплений простір, що збільшується без міграції даних, і природне місце для даних, яких ви не хочете тримати на продукційному сервері.

Об'єктне сховище не дає: семантики файлової системи (немає модифікації на місці, немає блокувань, немає справжніх каталогів), затримок на рівні локального диска, автоматичного захисту від видалення – якщо хочете пережити помилку користувача або ransomware, вам потрібні версіонування й незмінність об'єктів (Object Lock), а це треба свідомо ввімкнути. Саме лише шифрування у стані спокою також не захищає від витоку ключів доступу: хто має чинні облікові дані, той отримує дані розшифрованими. Безпека – це завжди сума шарів, а не один перемикач.

Як це виглядає в WebDisk

Наша об'єктна платформа працює на Ceph та його шлюзі S3 (RADOS Gateway) – відкритому програмному забезпеченні, яке використовують багато хмарних постачальників. Це не маркетингова деталь: це означає, що ви спілкуєтеся з нами тим самим API, яким спілкуєтеся з AWS, і тими самими клієнтами – s3cmd, awscli, boto3, rclone, плагінами в системах резервного копіювання.

Публічний ендпоінт – це https://s3.dco.webdisk.io. Сховище налаштоване під вартість зберігання великих наборів – архівів, резервних копій і медіа. Бакет можна зашифрувати на боці сервера (опція при його створенні, постійна). Версіонування та незмінність об'єктів (Object Lock) доступні – незмінність вмикається під час створення сховища і є незворотним рішенням. Вхід до S3 корпоративним обліковим записом (STS) готуємо як окрему послугу – сам механізм ми описали в статті, на яку посилаємося вище. Сховище замовляють у панелі, а простір докуповують у міру потреби. Актуальний набір функцій і прайс-лист ви знайдете на сторінці послуги Object Storage – а якщо вас цікавить, де фізично лежать ваші дані, ми писали про це в тексті про європейські хмарні обчислення.

Часті запитання

Чи треба бути програмістом, щоб користуватися S3?

Ні. Для ручної роботи вистачить графічних клієнтів (напр. Cyberduck, WinSCP, S3 Browser) або rclone у режимі синхронізації каталогу. Термінал зручний, але не обов'язковий.

Чим бакет відрізняється від мережевого диска?

Насамперед відсутністю файлової системи. До бакета ви не приєднаєте літеру диска й не відкриєте в ньому файл для редагування на місці – об'єкти завантажують і відсилають цілком. Натомість бакет доступний з будь-якого місця в інтернеті, а місткість ви збільшуєте, докуповуючи наступні пакети – без перенесення даних і без простою.

Чи існують у S3 каталоги та теки?

Ні – простір назв у бакеті є пласким. Скісні риски в ключі об'єкта (напр. 2026/07/raport.pdf) – це частина назви, а не вкладені теки; інструменти малюють дерево каталогів із префіксів для вашої зручності. Тому «перенесення каталогу» на практиці є копіюванням і видаленням кожного об'єкта окремо.

Чи дані в бакеті у безпеці, якщо хтось видалить файл?

Лише тоді, коли ви ввімкнете версіонування або блокування незмінності. Типово видалений об'єкт зникає. Це той самий принцип, що й для будь-якого іншого сховища: резервна копія та ретенція – це окреме рішення, а не вбудована властивість.

Як перенести кілька терабайтів від іншого постачальника?

Найпростіше rclone з налаштуванням двох віддалених сховищ – він копіює між ними безпосередньо і відновлює перерваний трансфер. За великих наборів варто підвищити паралельність (--transfers) і переносити дані префіксами.

Чи підходить S3 для даних, до яких я звертаюся раз на рік?

Так – і це один із найкращих сценаріїв. Архів в об'єктному сховищі коштує небагато, а дані лишаються доступними одразу, без відновлення зі стрічки.

Підсумок

Об'єктне сховище не є «кращим диском» – це інший інструмент, спроєктований під інший шаблон використання: запиши раз, читай багато разів, з багатьох місць, у масштабі, який ви не хочете планувати наперед. Коли цей шаблон пасує до ваших даних, S3 спрощує архітектуру більше, ніж будь-який доданий файловий сервер. Коли не пасує – краще знати про це, перш ніж застосунок почне воювати зі сховищем.

Маєте конкретний випадок і не знаєте, чи S3 є правильним вибором – або просто хочете спробувати? Напишіть нам: пройдемо через нього разом, допоможемо підібрати конфігурацію і видамо доступ до бакета.