Miten valita oikea suorittaja Apache Airflow'ssa?

Apache Airflow tarjoaa useita suorittajavaihtoehtoja, joilla on erilaisia etuja ja haasteita riippuen käytettävissä olevista resursseista ja työnkulun vaatimuksista. Yksi perusvalinta on Local Executor, joka tarjoaa yksinkertaisuutta ja nopeutta. Toinen suosittu vaihtoehto on Celery Executor, joka on suunniteltu laajamittaisempaan ja hajautettuun suoritukseen. Kolmas vaihtoehto, Kubernetes Executor, vie Airflow'n skaalautuvuuden ja resurssien hallinnan uudelle tasolle. Näiden eri suorittajien käytön ymmärtäminen ja vertailu auttaa päättämään, mikä niistä parhaiten vastaa organisaation tarpeita.

Local Executor

Local Executor on yksinkertainen ja nopea vaihtoehto, joka hyödyntää moniajoa tai rinnakkaisuutta suorittaakseen tehtäviä samanaikaisesti. Se on optimaalinen pienille ja keskikokoisille asennuksille, joissa ei ole tarvetta laajentaa kapasiteettia nopeasti. Esimerkiksi, jos sinulla on vain muutama itsenäinen tehtävä, jotka voivat suorittaa rinnakkain, Local Executor on riittävä valinta. Tässä asetuksessa määritellään, kuinka monta työntekijää (workers) käytetään tehtävien suorittamiseen. Käytännössä tämä tarkoittaa sitä, että työntekijät suorittavat tehtävät rinnakkain, ja näin parannetaan suorituskykyä.

Celery Executor

Celery Executor on hajautettu suorittaja, joka käyttää Celeryä, joka on tehtäväjonojärjestelmä, mahdollistamaan tehtävien suorittamisen useilla koneilla rinnakkain. Tällöin Airflow:lle ei ole enää rajoituksia yhdellä koneella tapahtuvaan suoritukseen, vaan työnkuormat voidaan jakaa useille koneille. Celery Executor hyödyntää viestinvälittäjää (kuten RabbitMQ tai Redis), joka hallitsee viestintää Airflow'n pääkomponentin ja työntekijäkoneiden välillä.

Tämä suorittaja on erityisen hyödyllinen silloin, kun tarvitaan laajennettavuutta ja hajautettua suoritusta. Celery Executorin etuja ovat muun muassa horisontaalinen skaalaus, mikä mahdollistaa työntekijäkoneiden lisäämisen ilman olemassa olevan infrastruktuurin muuttamista. Se myös mahdollistaa erilaisten työntekijäkoneiden määrittämisen erilaisten tehtävien suorittamiseen, optimoiden resurssien käytön.

Kubernetes Executor

Kubernetes Executor vie Apache Airflow'n suorittamisen pilveen ja konttiteknologioiden aikakauteen. Tämä suorittaja luottaa Kubernetesin kykyyn luoda dynaamisesti podit, jotka voivat suorittaa tehtäviä. Kubernetesin avulla voidaan tarjota skaalautuva ja joustava ympäristö, jossa resurssit, kuten CPU, muisti ja jopa GPU, jaetaan dynaamisesti sen mukaan, kuinka paljon niitä tarvitaan kunkin tehtävän suorittamiseen. Tämä tekee Kubernetes Executorista erityisen hyödyllisen suurten ja resurssintarpeiltaan monimutkaisten työnkulkujen suorittamiseen.

Kubernetes Executor mahdollistaa myös ympäristöjen eriyttämisen, jolloin voidaan käyttää erityisiä kontteja, jotka sisältävät tarkasti määritellyt ympäristöt ja kirjastot. Tämä on hyödyllistä silloin, kun tehtävät vaativat erityisiä ohjelmistoversioita tai ympäristöasetuksia. Sen lisäksi, Kubernetesin automaattinen vikasietoisuus ja virheiden käsittely tekevät siitä erittäin luotettavan vaihtoehdon hajautetussa ympäristössä.

Tällöin on kuitenkin muistettava, että Kubernetes Executorin käyttöönotto ja ylläpito voi olla monimutkaista. Kubernetes-klusterin luominen, erityisesti jos organisaatiossa ei ole aiempaa kokemusta, vaatii asiantuntemusta sekä pilviarkkitehtuurista että hajautetusta järjestelmästä. Lisäksi Kubernetesin hallinta voi lisätä ylläpitokustannuksia ja -monimutkaisuutta, erityisesti kevyiden tai nopeiden tehtävien kohdalla, joissa klusterin käynnistäminen saattaa aiheuttaa liikaa overheadia.

Yhteenveto

Apache Airflow'n suorittajavaihtoehdot tarjoavat joustavuutta ja tehokkuutta, mutta valinta riippuu pitkälti organisaation tarpeista ja infrastruktuurista. Local Executor on paras valinta yksinkertaisille ja pienille työnkuluillle, kun taas Celery Executor tarjoaa hajautettua suoritusta ja horisontaalista skaalautuvuutta suuremmille työnkuluille. Kubernetes Executor puolestaan vie Airflow'n hallinnan pilveen, mahdollistaen resursseiden dynaamisen allokoinnin ja erikoistuneiden ympäristöjen käytön, mutta se tuo mukanaan myös monimutkaisempia käyttöönotto- ja ylläpitovaatimuksia.

Jokaisella suorittajalla on omat hyvät ja huonot puolensa, ja valinta riippuu ennen kaikkea siitä, kuinka monimutkaiseksi ja laajaksi työnkulut tulevat. Vaikka Celery ja Kubernetes tarjoavat laajennettavuutta, niiden monimutkaisuus voi lisätä käyttöönoton ja ylläpidon haasteita. Tärkeintä on varmistaa, että valittu suorittaja tukee organisaation tarpeita sekä skaalautuvuuden että operatiivisten vaatimusten osalta.

Miten hallita salaisuuksia ja yhteyksiä Apache Airflow’ssa: Parhaat käytännöt ja testausmenetelmät

Salaisuuksien hallinta on keskeinen osa turvallisuuden varmistamista monimutkaisissa järjestelmissä, kuten Apache Airflow'ssa. Kun käsitellään arkaluontoisia tietoja, kuten API-avaimia, tietokantayhteyksiä ja salasanatietoja, oikean hallintaratkaisun valinta voi merkittävästi vaikuttaa järjestelmän luotettavuuteen ja turvallisuuteen. Ympäristömuuttujat ja salaisuuksien hallintapalvelut tarjoavat kaksi erilaista lähestymistapaa tähän haasteeseen.

Salaisuuksien hallintapalveluiden etuja on niiden kyky rotatoida, versioida ja auditoida sertifikaatteja ja salaisuuksia. Tämä ei ainoastaan paranna turvallisuutta, vaan se mahdollistaa myös ympäristöjen synkronoinnin, mikä on erityisen hyödyllistä, kun työskentelet useilla alustoilla tai useilla kehitysympäristöillä. Esimerkiksi jos kehitystiimisi käyttää salaisuuksien hallintapalvelua ja kaikki tiimin jäsenet yhdistävät siihen paikallisista ympäristöistään, on helppoa lisätä tai päivittää yhteyksiä ilman, että tarvitaan käsin konfigurointia jokaiselle käyttäjälle erikseen.

Salaisuuksien hallintapalveluiden käyttöönotossa Airflow'ssa on muutama keskeinen vaihe. Ensimmäinen askel on määrittää ympäristömuuttuja, joka osoittaa salaisuuksien tallennuspaikkaan. Tämä voidaan tehdä määrittämällä AIRFLOW__SECRETS__BACKEND-ympäristömuuttuja, joka kertoo, mitä salaisuuksien taustajärjestelmää käytetään. Tämän jälkeen salaisuudet on tallennettava oikealla etuliitteellä, jotta Airflow tunnistaa ne, esimerkiksi airflow/connections/ yhteyksille tai airflow/variables/ muuttujille.

Airflow 2.7:ssa otettiin käyttöön uusi ominaisuus nimeltä Salaisuuksien välimuisti (Secrets Cache). Tämä on kokeellinen ominaisuus, joka on oletusarvoisesti pois käytöstä konfiguraatiotiedostossa. Salaisuuksien hakeminen ulkoisesta hallintapalvelusta on verkko-operaatio, joka voi aiheuttaa suorituskykyongelmia ja hidastaa ajastimen toimintaa. Välimuistin käyttäminen salaisuuksien hakemiseen DAG-tulkinnan aikana voi lievittää tätä ongelmaa ja parantaa suorituskykyä. Välimuistin avulla voidaan myös vähentää kustannuksia, koska salaisuuksien hakeminen voi viedä yli 100 millisekuntia riippuen tallennuspaikasta ja hakemisen sijainnista.

Ympäristömuuttujien ja salaisuuksien hallintapalvelujen testaaminen on hieman erilaista verrattuna yhteyksien testaamiseen, jotka on tallennettu suoraan Airflow’n metadata-tietokantaan. Ympäristömuuttujissa tai salaisuuksien hallintapalveluissa tallennetut yhteydet eivät näy Airflow’n käyttöliittymässä tai komentorivillä, eikä niitä voi testata tavallisella Test Connection -painikkeella. Tässä tapauksessa testaus tapahtuu luomalla testidag, joka varmistaa, että Airflow pystyy käyttämään yhteyttä oikeassa työnkulussa.

Ympäristömuuttujien testaaminen voidaan tehdä luomalla yksinkertainen DAG, joka käyttää ympäristömuuttujassa tallennettua yhteyttä. Esimerkiksi, jos ympäristömuuttuja on nimeltään AIRFLOW_CONN_MYDB, voidaan luoda tehtävä, joka käyttää tätä yhteyttä. DAG käynnistetään ja lokit tarkistetaan, jotta voidaan varmistaa, että yhteys on onnistuneesti muodostettu. Jos yhteys on virheellinen, lokit näyttävät virheilmoituksen, kuten yhteyden epäonnistuminen.

Salaisuuksien hallintapalvelussa tallennettujen yhteyksien testaaminen noudattaa samankaltaista prosessia, mutta koska yhteydet on tallennettu ulkoiseen järjestelmään, testaus varmistaa, että Airflow pystyy hakemaan ja käyttämään salaisuuksia oikein. Salaisuuksien hallintapalvelun käyttöönottaminen edellyttää, että Airflow on konfiguroitu oikein käyttämään tätä palvelua, ja että tarvittavat ympäristömuuttujat on asetettu, kuten AIRFLOW__SECRETS__BACKEND.

Kun yhteyksiä testataan salaisuuksien hallintapalvelusta, voidaan luoda DAG, joka yrittää noutaa ja käyttää salaisuutta. Mikäli yhteyden hakeminen epäonnistuu, lokit kertovat mahdollisista ongelmista, kuten yhteyden puutteellisuudesta tai salaisuuksien puuttumisesta.

Parhaisiin käytäntöihin kuuluu valita oikea salaisuuksien hallintaratkaisu liiketoiminnan tarpeiden ja tavoitteiden mukaan. Jos tiimisi on suuri ja haluat skaalata nopeasti ja turvallisesti, salaisuuksien hallintapalvelu voi olla paras vaihtoehto. Toisaalta, jos olet yksittäinen kehittäjä, joka haluaa nopeasti testata paikallisella koneella, ympäristömuuttujat tai metadatatietokanta voivat olla helpompi ja nopeampi ratkaisu.

Yhteyksien ja salaisuuksien hallinta ei ole vain tekninen kysymys, vaan se liittyy tiimin ja organisaation kokoon, tarpeisiin ja tietoturvavaatimuksiin. On tärkeää muistaa, että vaikka yksinkertaisemmat ratkaisut voivat tuntua houkuttelevilta lyhyellä aikavälillä, pitkällä aikavälillä turvallisuus, hallittavuus ja skaalautuvuus ovat ratkaisevia tekijöitä, jotka vaikuttavat projektin menestykseen.

Miten luoda mittaristopaneeli liitännäisellä Airflowssa ja Flaskissa

Plugin-moduuliin luodaan hakemisto nimeltä metrics_plugin. Liitännäinen rekisteröidään ja Flaskin blueprint yhdistetään __init__.py-tiedostoon. Templates-hakemisto sisältää front-end HTML-koodin, joka on vastuussa mittaristopaneelin näyttämisestä. Lisäksi on olemassa views/dashboard.py-tiedosto, jossa toteutamme web-näkymän backend-koodin.

Näkymän toteutus

Ensimmäiseksi määritellään kaikki tarvittavat tuonnit näkymän toteuttamiseksi:

python
Copy code
from __future__ import annotations
from typing import TYPE_CHECKING
from airflow.auth.managers.models.resource_details import AccessView
from airflow.utils.session import NEW_SESSION, provide_session
from airflow.www.auth import has_access_view
from flask_appbuilder import BaseView, expose
from sqlalchemy import text
if TYPE_CHECKING:
    from sqlalchemy.orm import Session

Seuraavaksi määritellään MetricsDashboardView-luokka, joka määrittää reitin web-näkymälle:

python
Copy code
class MetricsDashboardView(BaseView):
    """Flask-AppBuilder View for a metrics dashboard"""
    default_view = "index"
    route_base = "/metrics_dashboard"

Tässä määritellään MetricsDashboardView-luokka ja asetetaan oletusarvot default_view ja route_base. default_view kertoo Flaskille, mikä funktio tulisi käyttää perusreitille. Tässä tapauksessa määritämme funktion nimeltä index. route_base puolestaan määrittää, että reitti on /metrics_dashboard, mikä tekee siitä käyttäjäystävällisemmän.

Viimeiseksi määritellään index-funktio, joka suorittaa tarvittavat kyselyt Airflow-tietokannassa mittareiden saamiseksi:

python
Copy code
@provide_session

@expose("/")
@has_access_view(AccessView.PLUGINS)
def index(self, session: Session = NEW_SESSION):
    """Create dashboard view"""
    def interval(n: int):
        return f"now() - interval '{n} days'"
    dag_run_query = text(
        f"""
        SELECT
            dr.dag_id,
            SUM(CASE WHEN dr.state = 'success' AND dr.start_date > {interval(1)} THEN 1 ELSE 0 END) AS "1_day_success",
            SUM(CASE WHEN dr.state = 'failed' AND dr.start_date > {interval(1)} THEN 1 ELSE 0 END) AS "1_day_failed",
            SUM(CASE WHEN dr.state = 'success' AND dr.start_date > {interval(7)} THEN 1 ELSE 0 END) AS "7_days_success",
            SUM(CASE WHEN dr.state = 'failed' AND dr.start_date > {interval(7)} THEN 1 ELSE 0 END) AS "7_days_failed",
            SUM(CASE WHEN dr.state = 'success' AND dr.start_date > {interval(30)} THEN 1 ELSE 0 END) AS "30_days_success",
            SUM(CASE WHEN dr.state = 'failed' AND dr.start_date > {interval(30)} THEN 1 ELSE 0 END) AS "30_days_failed"
        FROM dag_run AS dr
        JOIN dag AS d ON dr.dag_id = d.dag_id
        WHERE d.is_paused != true
        GROUP BY dr.dag_id
        """
    )
    dag_run_stats = [dict(result) for result in session.execute(dag_run_query)]
    return self.render_template(
        "dashboard.html",
        title="Metrics Dashboard",
        dag_run_stats=dag_run_stats,
    )

Tässä dag_run_query hakee kaikki DAG-ajot aktiivisista DAG:sta ja suorittaa aggregaatioita onnistuneiden ja epäonnistuneiden suoritusten laskemiseksi kolmelle eri aikavälille: 1 päivä, 7 päivää ja 30 päivää. Tämän jälkeen kyselyn tulokset muutetaan sanakirjojen listaksi nimeltä dag_run_stats, joka välitetään renderöitävään HTML-templaten. Tämä mahdollistaa Jinja-templaten käytön HTML-sivulla dynaamisesti luoduille mittareille.

HTML-template

Seuraavaksi luodaan HTML-template mittaristopaneelia varten templates/dashboard.html-tiedostoon. Airflow hyödyntää Bootstrap CSS:ää, joka helpottaa responsiivisen web-kokemuksen luomista ja Jinja-templatingia web-näkymien renderöintiin. Lisätään Airflow’n perus-templaatit HTML-tiedostoon, joka sisältää valikkopalkin ja muita HTML-osiota:

html
Copy code
{% extends base_template %}

{% block title %}
    {{ title }}
{% endblock %}
{% block head_meta %}
    {{ super() }}
{% endblock %}

Sitten määritellään sisältölohko, johon kaaviot tulevat näkymään. Koska kaaviot renderöidään JavaScriptin avulla, HTML-koodi on yksinkertainen:

html
Copy code
{% block content %}
    {{ title }}
    <div class="chart-container">

        <canvas id="successChart"></canvas>

        <canvas id="failedChart"></canvas>
    </div>
{% endblock %}

Tässä määritellään kaksi canvas-elementtiä, joiden ID:t ovat successChart ja failedChart, joihin onnistuneet ja epäonnistuneet DAG-suoritukset tullaan piirtämään.

Lopuksi määritellään tail-lohko, jossa määritellään JavaScript-koodi kaavioiden piirtämiseksi:

html
Copy code
{% block tail %}

    {{ super() }}
{% endblock %}

Mitä tulee huomioida?

Kun luot mittaristopaneelia Airflowssa, on tärkeää ottaa huomioon myös käyttäjän oikeudet. On ratkaisevaa varmistaa, että vain oikeutetut käyttäjät voivat käyttää tiettyjä näkymiä, jotta tietoturva säilyy. Tämän vuoksi on hyvä käyttää validointia ja oikeuksien tarkistamista jokaisessa reitissä, joka tarjoaa pääsyn arkaluonteisiin tietoihin.

Miten toteuttaa Airflowin siirto onnistuneesti?

Airflow on alun perin suunniteltu avoimeksi ja jaetuksi sovellukseksi, mutta tarvittaessa sen käyttöä voidaan muokata siten, että se tukee monen käyttäjän ympäristöjä. Tässä yhteydessä on olemassa useita strategioita, jotka pohjautuvat Airflowin arkkitehtuurisiin ja konfigurointimahdollisuuksiin. Mikään yksittäinen vaihtoehto ei välttämättä kata kaikkia tarpeitasi, mutta yhdistelmä näistä vaihtoehdoista voi auttaa saavuttamaan niin turvallisuus- kuin operatiiviset tavoitteet. On hyvä muistaa, että mahdollisuus täysin eristettyyn ympäristöön on aina olemassa, jos päätetään ottaa käyttöön erillinen Airflow-lisäasennus.

Kun järjestelmä tai infrastruktuuri kokee muutoksia, kuten uudet teknologiat, infrastruktuurin muutokset tai katastrofipalautukset, on yleensä tarpeen siirtää tietoja tai järjestelmiä. Tällaisessa siirrossa, joka menee huonosti, on usein merkittäviä vaikutuksia liiketoiminnan prosesseihin ja toimintoihin. Siksi on elintärkeää panostaa riittävästi suunnitteluun ja riskien hallintaan, jotta siirrosta tulee onnistunut.

Tekniset vaatimukset

Yleiset hallintatoimet migraation yhteydessä

Migraatioon liittyy aina yleisiä toimintoja, jotka ovat tarpeen riippumatta siitä, mistä ja minne ollaan siirtymässä. Ensimmäinen askel on tehdä täydellinen inventaario kaikista siirrettävistä työnkulkuista. Luetteloi kaikki työnkulut ja kerää seuraavat tiedot: kuka omistaa työnkulun teknisesti ja liiketoimintatasolla, mitä tietolähteitä ja määränpäitä työnkulku käyttää, ja kuinka kriittinen se on liiketoiminnan kannalta. Tässä vaiheessa on tärkeää myös vastata kysymyksiin, kuten:

• Missä työnkulun koodi ja konfiguraatio sijaitsevat?

• Kuinka usein työnkulku suoritetaan?

• Millaisia poikkeuksia tai testejä on laadittu kyseiselle työnkululle?

• Miltä näyttää, kun työnkulku toimii oikein?

• Miten työnkulku on rikkoutunut aiemmin?

• Kuinka vakavaa on, jos työnkulku ei toimi jollain aikavälillä?

Kun tämä perusinformaatio on kerätty, työnkulut voidaan jakaa työryhmiin ja priorisoida liiketoiminnan kriittisyyden mukaan. Tämä vaihe voi paljastaa piileviä töitä, sillä joskus työnkulun alkuperäiset tekijät eivät enää ole organisaatiossa. Lisäksi aikarajat ja mahdolliset muutosaikataulut voivat tulla esiin tässä vaiheessa, kun tiedetään, kuinka kauan siirto voi kestää ja milloin se voidaan suorittaa. Tärkeintä tässä vaiheessa on varmistaa, että kaikki sidosryhmät ovat tietoisia tarvittavista toimenpiteistä ja niiden vaikutuksista päivittäiseen toimintaan.

Migraation toteutus

Kun suunnitteluvaihe on valmis, voidaan siirtyä itse siirtotöihin. Tämä vaihe on hyvin tekninen ja monille kehittäjille tuttu. Siirron aikana on kuitenkin muutama tärkeä perusohje, joita kannattaa noudattaa:

• Vähimmäispariteetti: Siirrä työnkulut niin, että ne toimivat vähintään yhtä hyvin kuin alkuperäiset. Älä yritä refaktoroida koodia, jos alkuperäiset mallit toimivat. Koodin rumuus on parempi kuin uuden koodin täydellisyys.

• Tekninen velka: Siirron aikana voi ilmetä teknistä velkaa, jota on tärkeää seurata. Älä yritä ratkaista velkaa siirron aikana, vaan tee merkintöjä ja mieti myöhemmin, miten velka maksetaan.

• Testaus: Hyödynnä olemassa olevia QA-testitapauksia. Jos niitä ei ole, kannattaa dokumentoida niitä yhteistyössä teknisten ja liiketoiminnallisten sidosryhmien kanssa. Testaa työnkulut eristetyissä ympäristöissä, käyttämällä mahdollisuuksien mukaan tuotantodataa ja -skaalaa. Suorita erityisesti laajempaa testausta kriittisissä työnkuluissa, joissa häiriöillä voi olla erityisen tuhoisia seurauksia.

Migraation aikana seuranta ja tiedon jakaminen

Tekniset lähestymistavat migraatioon

Tässä osiossa tarkastellaan useita teknisiä ratkaisuja, jotka voivat helpottaa siirrossa tavallisesti esiintyviä haasteita. Ei kaikki nämä ratkaisut sovellu jokaiseen tilanteeseen, mutta ne kannattaa ottaa huomioon migraation suunnitteluvaiheessa.

• Koodin migraation automatisointi: Jos siirrettäviä työnkulkuja on paljon, koodin automaattinen siirtäminen voi olla järkevää. Tässä vaiheessa ei ole syytä pyrkiä täydellisyyteen. Riittää, että saadaan “hyväksyttävä” tulos, koska migraatio tehdään vain kerran.

• QA/testausdokumentaation luominen: Jos mahdollista, kannattaa perustaa virallinen QA-suunnitelma ja ympäristö siirron tukemiseksi. Käytä sekä tuotantoympäristöä että UAT-ympäristöä (User Acceptance Testing), joka toimii peilinä tuotantoympäristölle, mutta vain lukuoikeuksilla tietolähteisiin.

Kun nämä perusperiaatteet ja lähestymistavat ovat hallussa, on mahdollista siirtää Airflow-ympäristöt tehokkaasti ja riskit halliten. Migraation onnistumisen kannalta on oleellista, että kaikki siirtoon osallistuvat osapuolet ymmärtävät prosessin vaiheet ja ovat valmiita reagoimaan nopeasti mahdollisiin esteisiin.