Self-hosting analytickej infraštruktúry vám dáva úplnú kontrolu nad dátami, eliminuje závislosť na dodávateľovi a pri väčšom rozsahu môže výrazne znížiť náklady. Návrh robustnej self-hosted architektúry však vyžaduje starostlivé plánovanie naprieč viacerými dimenziami: vysoká dostupnosť, škálovateľnosť, bezpečnosť a prevádzková efektivita.

Tento sprievodca pokrýva architektonické vzory a osvedčené postupy pre nasadenie ClickHouse, Matomo a súvisiacich analytických komponentov vo vašej vlastnej infraštruktúre.

⚠️ Dôležitá poznámka o PostHog Self-Hostingu: Od roku 2024 PostHog už nepodporuje produkčne škálované self-hosted nasadenia. Ich Kubernetes nasadenie bolo ukončené (bezpečnostné aktualizácie skončili v máji 2024) a open-source Docker Compose nasadenie je určené len pre hobby použitie (približne 100 000 eventov/mesiac). Pre produkčné workloady PostHog odporúča ich Cloud ponuku. Tento sprievodca sa zameriava na ClickHouse a Matomo pre self-hosted analytiku, ktoré zostávajú plne podporované pre produkčné nasadenia.

Prehľad architektúry

Produkčne pripravený self-hosted analytický stack typicky pozostáva z niekoľkých prepojených vrstiev:

  • Ingestion vrstva: Spracováva prichádzajúce udalosti z SDK a API
  • Spracovateľská vrstva: Transformuje, obohacuje a validuje dáta udalostí
  • Úložná vrstva: Uchováva dáta pre dotazovanie a dlhodobú retenciu
  • Dotazovacia vrstva: Slúži dashboardom, reportom a ad-hoc analýzam
  • Aplikačná vrstva: Analytické UI a API endpointy

Vzory vysokej dostupnosti

Pre produkčné workloady sú single points of failure neprijateľné. Tu je návod, ako navrhnúť vysokú dostupnosť:

Multi-node nasadenia

Spustite viacero inštancií každého komponentu za load balancermi:

# Príklad: HAProxy konfigurácia pre analytics frontend
frontend analytics_frontend
    bind *:443 ssl crt /etc/ssl/analytics.pem
    default_backend analytics_servers

backend analytics_servers
    balance roundrobin
    option httpchk GET /health
    server analytics1 10.0.1.10:8000 check
    server analytics2 10.0.1.11:8000 check
    server analytics3 10.0.1.12:8000 check

Replikácia databázy

Nakonfigurujte PostgreSQL so streaming replikáciou pre aplikačnú databázu:

  • Primary: Spracováva všetky write operácie
  • Standby: Synchrónne alebo asynchrónne repliky pre čítanie a failover
  • Automatický failover: Použite Patroni (odporúčané pre komplexné nasadenia), repmgr alebo pg_auto_failover (najjednoduchšia možnosť)

Patroni je najkompletnejšia možnosť, využívajúca distribuované konfiguračné úložiská ako etcd pre konsenzus. Pre jednoduchšie nastavenia pg_auto_failover poskytuje ľahšiu cestu so svojou architektúrou založenou na monitore.

Dizajn ClickHouse clusteru

ClickHouse je motor za vysoko výkonnými analytickými dotazmi. Pre vysokú dostupnosť použite ClickHouse Keeper (odporúčané) namiesto ZooKeeper pre koordináciu clusteru. ClickHouse Keeper poskytuje lepšiu spoľahlivosť, používa menej zdrojov a je špeciálne navrhnutý pre ClickHouse:

<!-- clickhouse-config.xml -->
<remote_servers>
    <analytics_cluster>
        <shard>
            <internal_replication>true</internal_replication>
            <replica>
                <host>clickhouse-01</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>clickhouse-02</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>clickhouse-03</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <internal_replication>true</internal_replication>
            <replica>
                <host>clickhouse-04</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>clickhouse-05</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>clickhouse-06</host>
                <port>9000</port>
            </replica>
        </shard>
    </analytics_cluster>
</remote_servers>

<!-- ClickHouse Keeper konfigurácia (na dedikovaných keeper nodoch) -->
<keeper_server>
    <tcp_port>2181</tcp_port>
    <server_id>1</server_id>
    <raft_configuration>
        <server>
            <id>1</id>
            <hostname>keeper-01</hostname>
            <port>9234</port>
        </server>
        <server>
            <id>2</id>
            <hostname>keeper-02</hostname>
            <port>9234</port>
        </server>
        <server>
            <id>3</id>
            <hostname>keeper-03</hostname>
            <port>9234</port>
        </server>
    </raft_configuration>
</keeper_server>

Kľúčové úvahy pre ClickHouse clustery:

  1. Sharding: Distribuujte dáta naprieč shardmi pre horizontálne škálovanie zápisov
  2. Replikácia: Každý shard by mal mať 3 repliky pre vysokú dostupnosť (umožňuje jeden výpadok pri zachovaní kapacity obnovy)
  3. ClickHouse Keeper: Nasaďte ako 3 alebo 5 nodový ensemble na dedikovaných hostoch; Keeper je citlivý na latenciu disk I/O, preto použite SSD
  4. Availability Zones: Distribuujte repliky naprieč rôznymi availability zónami s latenciou round-trip menej ako 20ms
  5. Table Engines: Vždy používajte ReplicatedMergeTree alebo podobné replikované enginy pre dáta, ktoré chcete uchovať

Architektúra Matomo

Matomo zostáva plne podporované pre self-hosted produkčné nasadenia a dokáže spracovať viac ako 1 miliardu pageviews mesačne so správnou architektúrou.

Štandardné nasadenie

# Matomo komponenty
- PHP Aplikácia (viacero podov za LB)
- MySQL/MariaDB (primary + replica)
- Redis (session storage, caching)
- Archiving Cron (dedikovaný worker)

Konfigurácia pre vysoký objem

Pre stránky spracovávajúce milióny pageviews Matomo odporúča vrstvenú architektúru:

  • Jeden server: Vhodný pre menšie stránky s adekvátnym hardvérom (4 CPU, 8GB RAM, 250GB SSD minimum)
  • Multi-server setup: 2+ Matomo servery so zdieľaným úložiskom a jednou databázou
  • Enterprise architektúra: Oddelené tracking servery od reporting/API serverov, dedikovaní archiving workeri, databázový cluster s failoverom

Esenciálne pluginy a konfigurácie pre vysoký traffic:

  • QueuedTracking plugin: Bufferujte tracking požiadavky v Redise pred spracovaním na zvládnutie traffic špičiek
  • Redis pre sessions: Nakonfigurujte Redis pre session handling v load-balanced prostrediach
  • Vypnite browser archiving: Nastavte enable_browser_archiving_triggering = 0 a používajte cron-based archiving
  • Vylaďte archiving interval: Zvýšte time_before_today_archive_considered_outdated (napr. 3600 sekúnd pre hodinové spracovanie)

Sieťová architektúra

Správny návrh siete je kritický pre bezpečnosť a výkon:

Sieťová segmentácia

# Príklad sieťovej topológie
Public Subnet (DMZ):
  - Load Balancery
  - CDN Edge
  - WAF/DDoS Ochrana

Private Subnet (Aplikačná):
  - Matomo PHP
  - API Gateway
  - Aplikačné servery

Private Subnet (Dátová):
  - ClickHouse Cluster
  - PostgreSQL
  - Redis Cluster
  - Kafka Cluster (ak sa používa)

Management Subnet:
  - ClickHouse Keeper nody
  - Monitoring (Prometheus, Grafana)
  - Bastion hosty

Bezpečnostné úvahy

  • TLS všade: Šifrujte všetku komunikáciu, vrátane interných služieb; používajte TLS 1.3, kde je to možné
  • Sieťové politiky: Obmedzte traffic medzi komponentmi pomocou security groups alebo Kubernetes network policies
  • Privátne endpointy: Držte databázy mimo verejných sietí; používajte VPC endpointy pre cloud služby
  • VPN/Bastion: Zabezpečte administratívny prístup cez jump hosty alebo VPN
  • Správa secrets: Používajte HashiCorp Vault, AWS Secrets Manager alebo podobné pre správu credentials

Ingestion endpointy

Pre globálne nasadenia zvážte edge ingestion:

  • Nasaďte ľahké kolektory vo viacerých regiónoch
  • Použite Kafka alebo podobné riešenie pre spoľahlivý cross-region transport s exactly-once sémantikou
  • Centralizujte spracovanie v primárnom datacentre
  • Zvážte CDN-level zber dát pre zníženú latenciu

Architektúra úložiska

Analytické workloady sú náročné na úložisko. Plánujte zodpovedajúco:

ClickHouse úložisko

  • NVMe SSD: Esenciálne pre výkon dotazov na horúcich dátach
  • Vrstvené úložisko: Horúce dáta na SSD, studené dáta na HDD alebo object storage (S3/GCS)
  • Kompresia: LZ4 pre rýchlosť, ZSTD pre lepšie kompresné pomery na studených dátach

Nakonfigurujte politiky vrstveného úložiska v XML konfigurácii (nie SQL):

<!-- /etc/clickhouse-server/config.d/storage.xml -->
<clickhouse>
    <storage_configuration>
        <disks>
            <nvme_disk>
                <path>/var/lib/clickhouse/hot/</path>
            </nvme_disk>
            <s3_disk>
                <type>s3</type>
                <endpoint>https://s3.amazonaws.com/your-bucket/clickhouse/</endpoint>
                <access_key_id>YOUR_ACCESS_KEY</access_key_id>
                <secret_access_key>YOUR_SECRET_KEY</secret_access_key>
                <metadata_path>/var/lib/clickhouse/disks/s3/</metadata_path>
            </s3_disk>
        </disks>
        <policies>
            <tiered_policy>
                <volumes>
                    <hot>
                        <disk>nvme_disk</disk>
                        <move_factor>0.1</move_factor>
                    </hot>
                    <cold>
                        <disk>s3_disk</disk>
                        <prefer_not_to_merge>true</prefer_not_to_merge>
                    </cold>
                </volumes>
            </tiered_policy>
        </policies>
    </storage_configuration>
</clickhouse>

Aplikujte storage policy na tabuľky pomocou TTL pravidiel:

CREATE TABLE events (
    event_date Date,
    event_time DateTime,
    user_id UInt64,
    event_type String,
    properties String
) ENGINE = ReplicatedMergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_type, event_date, user_id)
TTL event_date + INTERVAL 30 DAY TO VOLUME 'cold'
SETTINGS storage_policy = 'tiered_policy';

Plánovanie kapacity

Odhadnite potreby úložiska na základe objemu udalostí:

  • Surové udalosti: ~0.5-1KB na udalosť (komprimované s LZ4)
  • Session recordings: ~100KB-1MB na session (ak sa používajú)
  • Retencia: Plánujte 1-3 roky dotazovateľných dát
  • Buffer rastu: Pridajte 30-50% overhead pre merge a dočasné dáta

Príklad výpočtu:

Mesačné udalosti: 100M
Úložisko na udalosť: 0.75KB (komprimovaný priemer)
Mesačný nárast: 75GB
3-ročná retencia: 2.7TB
S 40% bufferom: ~3.8TB horúce úložisko
Studené úložisko (S3): Plánujte 5x pre historické dáta

Stratégie zálohovania

Strata dát je katastrofická. Implementujte komplexné stratégie zálohovania:

ClickHouse zálohy

ClickHouse poskytuje natívne backup príkazy, ktoré podporujú lokálny disk, S3 a Azure Blob Storage:

-- Plná záloha databázy do S3
BACKUP DATABASE analytics TO S3(
    'https://s3.amazonaws.com/your-bucket/backups/full_2025_01_22',
    'ACCESS_KEY',
    'SECRET_KEY'
);

-- Inkrementálna záloha (referencovanie predchádzajúcej zálohy)
BACKUP DATABASE analytics TO S3(
    'https://s3.amazonaws.com/your-bucket/backups/incr_2025_01_23',
    'ACCESS_KEY',
    'SECRET_KEY'
) SETTINGS base_backup = S3(
    'https://s3.amazonaws.com/your-bucket/backups/full_2025_01_22',
    'ACCESS_KEY',
    'SECRET_KEY'
);

-- Obnova zo zálohy
RESTORE DATABASE analytics FROM S3(
    'https://s3.amazonaws.com/your-bucket/backups/full_2025_01_22',
    'ACCESS_KEY',
    'SECRET_KEY'
);

Pre komplexnejšie backup workflows nástroj clickhouse-backup od Altinity poskytuje dodatočné funkcie ako paralelné uploady, kompresné možnosti a integráciu s rôznymi storage backendmi.

Databázové zálohy

  • PostgreSQL: pg_dump pre logické zálohy, pg_basebackup pre fyzické; zvážte pgBackRest pre produkciu
  • MySQL/MariaDB: mysqldump alebo Percona XtraBackup pre hot zálohy

Plán zálohovania

# Odporúčaný plán zálohovania
- Plná záloha: Týždenne (nedeľa 02:00 UTC)
- Inkrementálna: Denne (02:00 UTC)
- Transakčné logy/WAL: Kontinuálny streaming
- Retencia: 30 dní pre denné + mesačné archívy na 1 rok
- Off-site replikácia: Ihneď po dokončení zálohy

Validácia záloh

Netestované zálohy nie sú zálohy:

  1. Automatizované testy obnovy: Týždenná obnova do staging prostredia
  2. Kontroly integrity: Overujte checksums záloh a konzistenciu dát
  3. Validácia RTO/RPO: Dokumentujte a testujte, že obnova spĺňa biznis požiadavky
  4. Testovanie runbookov: Zabezpečte, že operačný tím dokáže vykonať procedúry obnovy

Disaster Recovery

Plánujte pre kompletné zlyhanie infraštruktúry:

  • Cross-region replikácia: Replikujte kritické dáta do sekundárneho regiónu
  • Infrastructure as Code: Terraform, Pulumi alebo OpenTofu pre rýchle opätovné nasadenie
  • Runbooky: Dokumentované postupy pre scenáre obnovy s jasným vlastníctvom
  • Pravidelné DR cvičenia: Testujte postupy obnovy kvartálne; dokumentujte výsledky a zlepšenia

Monitoring a pozorovateľnosť

Nemôžete spravovať to, čo nemôžete merať:

Odporúčaný monitoring stack

  • Metriky: Prometheus + Grafana (alebo Victoria Metrics pre škálu)
  • Logy: Loki, Elasticsearch alebo samotný ClickHouse
  • Tracing: Jaeger alebo Tempo pre distribuovaný tracing
  • Alerting: Alertmanager s integráciou PagerDuty/Opsgenie

Kľúčové metriky

  • Ingestion: Udalosti za sekundu, percentily latencie (p50/p95/p99), miera chýb, hĺbka fronty
  • Úložisko: Využitie disku podľa volume, lag replikácie, veľkosť merge fronty, počet partov
  • Dotazy: Latencia dotazov p50/p95/p99, súbežné dotazy, zlyhané dotazy, slow query log
  • Systém: Využitie CPU, pamäte, sieťová priepustnosť, latencia disk I/O
  • Zdravie clusteru: Dostupnosť nodov, stav Keeper/ZooKeeper sessions, stav replikácie

Prahy alertov

# Príklad alertovacích pravidiel
- Latencia ingestie p95 > 5s po dobu 5 minút: Warning
- Latencia ingestie p95 > 30s po dobu 5 minút: Critical
- Lag replikácie > 30s: Warning, > 5 minút: Critical
- Využitie disku > 70%: Warning, > 85%: Critical
- Dotazy p99 > 30s: Warning
- Keeper quorum stratený: Critical
- Akákoľvek replika v readonly mode: Critical
- Zlyhanie zálohy: Critical

Úvahy o škálovaní

Navrhujte pre rast od začiatku:

Horizontálne škálovanie

  • Bezstavové služby: Pridajte repliky za load balancer; používajte Kubernetes HPA pre auto-scaling
  • ClickHouse: Pridajte shardy pre škálovanie zápisov, repliky pre škálovanie čítania; plánujte sharding stratégiu včas, keďže resharding je komplexný
  • Kafka: Pridajte partície pre paralelizmus, brokery pre priepustnosť

Vertikálne škálovanie

  • ClickHouse: Výrazne benefituje z väčšej RAM (pre cache) a rýchlejšieho úložiska; vylaďte max_server_memory_usage vhodne
  • PostgreSQL: Viac RAM pre shared_buffers (typicky 25% RAM) a work_mem

Sharding stratégia

Vyberte sharding kľúč, ktorý distribuuje dáta rovnomerne. Vyhýbajte sa kľúčom, ktoré vytvárajú hotspoty (napr. timestamps, sekvenčné ID). Dobrí kandidáti zahŕňajú hashe user_id alebo kompozitné kľúče. Aplikujte schéma zmeny naprieč všetkými shardmi pomocou ON CLUSTER klauzuly.

Optimalizácia nákladov

Self-hosting by mal byť nákladovo efektívny:

  • Správna veľkosť inštancií: Monitorujte skutočné využitie a upravte; vyhýbajte sa over-provisioningu
  • Rezervovaná kapacita: Záväzok na 1-3 roky pre 30-60% úspory na compute
  • Spot/Preemptible inštancie: Použite pre nekritické batch spracovanie a vývoj
  • Životný cyklus dát: Implementujte automatizované TTL politiky; archivujte alebo vymažte dáta, ktoré už nie sú potrebné
  • Vrstvenie úložiska: Presúvajte studené dáta na lacnejšie object storage
  • Kompresia: Používajte ZSTD pre studené dáta na zníženie nákladov na úložisko

Úvahy o Kubernetes nasadení

Ak nasadzujete na Kubernetes:

  • Operátory: Použite Altinity Operator pre ClickHouse pre zjednodušenú správu clusteru
  • StatefulSets: Vyžadované pre stavové komponenty (ClickHouse, PostgreSQL, Kafka)
  • Persistent Volumes: Používajte vysoko výkonné storage classes; vyhýbajte sa network-attached storage pre ClickHouse ak je to možné
  • Pod Disruption Budgets: Zabezpečte dostupnosť počas údržby nodov
  • Resource requests/limits: Nastavte vhodne na predchádzanie noisy neighbor problémom
  • Anti-affinity pravidlá: Distribuujte repliky naprieč nodmi a availability zónami

Ďalšie kroky

Budovanie self-hosted analytickej infraštruktúry je významný podnik. Začnite s:

  1. Dokumentujte požiadavky: Projekcie objemu, retenčné politiky, SLA dostupnosti, compliance požiadavky
  2. Vyberte platformu nasadenia: VM, Kubernetes alebo hybrid na základe expertízy tímu
  3. Začnite malým a iterujte: Začnite s minimálnym životaschopným nasadením; vyhýbajte sa predčasnej optimalizácii
  4. Investujte do automatizácie: Infrastructure as Code od prvého dňa; GitOps pre správu konfigurácie
  5. Plánujte prevádzku: Monitoring dashboardy, alerting, overenie záloh, incident response procedúry
  6. Budujte expertízu: Investujte do školení; zvážte vendor support kontrakty pre kritické komponenty

Dobre navrhnutá self-hosted architektúra poskytuje základ pre analytiku, ktorá škáluje s vaším biznisom a zároveň udržuje vaše dáta pod vašou kontrolou. Pamätajte, že operačná záťaž je významná—starostlivo zvážte výhody self-hostingu voči spravovaným službám pre váš konkrétny prípad použitia.