Hovedsaklig møtte vi på to problemer: ingen flere ledige inodes, og lang venting på å liste ut alle filene, med millioner av filer lagret i én og samme katalog.

Filene ble lagret på filsystemet EXT4 i Linux, Ubuntu 14.04.1 LTS.

EXT4 har en fastsatt grense for antall filer som filsystemet kan håndtere, og denne settes under oppretting av filsystemet, så denne kunne vi ikke endre.
Videre klarer ikke EXT4 å håndtere stort mer enn ca 100k filer i én og samme katalog uten at alt går i sneglefart.

Vi måtte finne et nytt filsystem, noe som ikke hadde noen øvre grense for antall filer, med unntak av diskplass så klart.

Andre filsystemer til unnsetning

Vi måtte gjøre noen tester for å finne ut hvilket filsystem vi kan bruke istedenfor EXT4.
Kandidatene vi kom fram til var BTRFS, XFS og ZFS.

I tillegg vurderte vi OneFS, et produkt fra Isilon som vi allerede har kjørende i produksjon, et nettverkslagringssystem som er spesialisert til å håndtere veldig store datamengder, men dette produktet er heller ikke bra til å håndtere veldig mange filer i én katalog.
Vi kan rett og slett ikke bruke den på grunn av risiko for å krasje hele filsystemet og ta med oss alle andre systemer i produksjon som bruker dette.

Testingen jeg gjorde er relativt enkel:

1. Opprettet tomme filer på 20 GB, loopback-montert og formattert med filsystemet som skulle testes
2. Kopierte 1.6M (1.644.553) filer på til sammen 19 GB, alle i én katalog, til hver av filsystemene
3. Tømte Linux OS-cache før testing av hvert filsystem
4. Tok tiden for detailjert sortert utlisting (kald test)
5. Tok tiden for detailjert sortert utlisting enda en gang (varm test)
6. Tok tiden for usortert utlisting (varm test)

I tillegg tok jeg noen notater om komprimeringsgrad for de filsystemene som støttet komprimering, og hvor mye OS-cache og minne som ble brukt etter gjennomført testing.
Maskinene har noen bakgrunnsprosesser som vil kunne allokerer noe minne mens testene kjøres, men jeg anses aktiviteten på disse som lite i forhold til ressursbeslaget disse testene vil gjøre.

Hastighet på lesing eller skriving av innholdet i filene er ikke det viktigste for oss.
Det er små filer, fra 50 KB til 500 KB, så det er viktigere at vi kan lese flere filer raskt enn å lese én stor fil raskt.

Vi trenger et filsystem som lar oss jobbe med filene, skrive nye filer, flytte filer og kopiere filer når behovene melder seg, istedenfor å krype stille sammen for å dø – altså er uthenting av metadata om filer og utlisting av filene viktige kriterier.

For å tømme OS-cache på Linux kjørte jeg følgende kommando:

echo 3 | sudo tee /proc/sys/vm/drop_caches

For utføring av testen “detailjert sortert utlisting” kjørte jeg følgende kommando:

time ls -lht KATALOG | wc -l

For utføring av testen “usortert utlisting” kjørte jeg følgende kommando:

time ls -1 -U KATALOG | wc -l

Disse kommandoene tar tiden for å liste ut filer.
I steden for å bruke tid på å printe ut all teksten til konsollet så gjorde jeg en telling av linjer, som også ble en verifikasjon på at jeg hadde kopiert over alle filene til alle filsystemene som ble testet.

Testoppsett

Filene lå opprinnelig på Server1 på et EXT4-filsystem.
Disse ble kopiert over til Server2 hvor testene av de andre filsystemene ble gjort.
Server2 hadde omtrent ingen annen aktivitet mens testene pågikk, så målingene skal være nokså nøyaktige.
For å måle opp mot problemet vårt ble også testene gjennomført på Server1 mot EXT4.
I tillegg gjennomførte jeg en test på Server1 over NFS mot XFS-filområdet til Server2.

Filsystemene ble i hovedsak opprettet med standard-opsjoner på Ubuntu 14.04.1 LTS.
Komprimering ble aktivert i BTRFS og ZFS.

Resultater

På Server1 gjennomførte jeg en tømming av OS-cache, men målte ikke minneallokeringsbruk, da det er andre tjenster som kjører på serveren, og det kunne gitt villedende resultater.

NFS-testen fra Server1 mot Server2 sitt XFS-testoppsett mangler noen måletall, tall jeg anså som uviktige å måle på grunn av nettverksseparasjonen.
Den kalde testen av detaljert utlisting av filer ble ikke gjennomført over NFS.

Skriving av filer til ZFS ble merkbart tregere for hver fil som ble skrevet – i starten var overføringshastigheten over 6.5 MB/s, men slutta på 3.2 MB/s.
Usikkert om det skyldes komprimering, diskstørrelse eller andre årsaker.

Tid ble målt i minutter og sekunder.
BTRFS, XFS og ZFS allokerer inodes dynamisk.

EXT4 var eneste som hadde et maksimalt antall inodes.
BTRFS rapporterte ikke om inodes i “df -i”, verken ledige eller brukte.
Både XFS og ZFS var fleksible i ledige inodes som ble rapportert og endret seg i takt med ledig diskplass.

Alle filsystemene gjennomførte testene innen akseptabel hastighet når systemet var varm.
Allikevel var BTRFS og XFS de raskeste her med svar på under 20 sekunder, mens ZFS brukte 33 sekunder og EXT4 brukte 44 sekunder.

XFS var klart raskest når systemet var kald med svar på under 2 minutter.
EXT4 og BTRFS var nokså like med omkring 3,5 minutter når systemet var kald.
ZFS brukte uakseptabel lang tid (over 8 minutter) når systemet var kald.

EXT4, BTRFS og XFS leverte et akseptabelt raskt svar på usortert utlisting av filene, på maksimalt 2 sekunder.
XFS var raskest, på 1 sekund.
ZFS brukte uakseptable 15 sekunder.

Alle filsystemene unntatt EXT4 allokerte mye minne og cache for å utføre testene.
Det er usikkert om loopback-monteringen på Server2 kan ha hatt innvirkning.
EXT4 allokerte bare 109 MB som cache, men den var også noe tregere enn de andre når systemet var varm.
XFS allokerte 3.5 GB minne, hvorav 830 MB cache.
ZFS allokerte 3.3 GB minne, hvorav 1.4 GB cache.
BTRFS allokerte 5.9 GB minne, hvorav 3.7 GB cache.

Konklusjon

Vi anså XFS til å være best for våre behov.
Den leverte svar innen akseptabel tid både da systemet var kaldt og varmt, og var også den raskeste til å levere usortert utlisting av filene.

ZFS skuffet stort med uakseptabelt trege svar.
BTRFS brukte for mye minne, men ellers virket den lovende.

Felles for både BTRFS og ZFS var at komprimering var aktivert.
Kanskje kunne minnebruken vært lavere for både BTRFS og ZFS om testingen ble utført uten komprimering.

Det er god aktivitet rundt BTRFS i Linux-kildekoden og ser ut til å bli arvtakeren til EXT3/4.
BTRFS har funksjoner for blant annet komprimering og snapshotting, og det vil være aktuelt med ny vurdering av BTRFS senere.

Avslutning-rant

Etter at ny diskenhet ble koblet til Server1 og XFS ble satt opp, så dukket et nytt problem fram – overføring av filene fra EXT4-partisjonen til den nye XFS-partisjonen gikk i trege 1 MB/s.
Løsningen ble å overføre filene tilbake fra Server2 sitt XFS-filsystem over NFS…

Et enda større problem møtte vi med en annen katalog, som inneholder omkring 1.1 millioner kataloger, som igjen inneholder filer, men mer om dette kan diskuteres over et par kanner kaffe – jeg har god tid…

Vi har lenge lagret RDF-grafer som filer på disk, men har den siste tida undersøkt flere RDF-databaser.

Felles for de fleste grafdatabaser er at de trives best i RAM.
Store installasjoner som skryter av å lagre milliarder av tripler består enten av servere med masse minne, eller av mange maskiner i et kluster som tilsammen innehar mye minne – da snakker vi størrelsesorden hundrevis av GB RAM.

Tidligere tester av RDF-databaser

Vi har tidligere testet Jena Fuseki og OpenLink Virtuoso, men begge har sine irriterende problemer.

Jena Fuseki TDB

Jena Fuseki med TDB blir fort ubrukelig når databasen blir større enn Java heap-size, og den feiler ofte med OutOfMemoryError.
Testet med 4 GB Java-heap.

OpenLink Virtuoso

OpenLink Virtuoso har vi testet i versjon 6 og versjon 7.
Versjon 6, som følger med i pakkesystemet til Ubuntu, støttet ikke SPARQL UPDATE.
Versjon 7 feiler når vi prøver å laste inn grafer som inneholder mange blank nodes, selv om vi klarte å hacke oss til en løsning ved å splitte opp insertene i mindre deler.
Generelt sett har Virtuoso flere irriterende problemer, blant annet at den ikke forstår “INSERT DATA” fra SPARQL UPDATE – her måtte vi bruke “INSERT INTO”.

Bigdata

Jeg har i noen dager testet Bigdata, en server for lagring og spørring over RDF-data.

Bigdata-serveren er en Java-applikasjon som kjører i en standard Servlet applikasjons-container.

Innlasting av data

Datagrunnlaget er oppdelt i 525K (525.000) grafer – dokumenter i RDF/TURTLE-format.

Grafene inneholder mange blank nodes, ressurser som ikke er navngitte og globalt identifisérbare med IRI.
Grunnen til at vi bruker blank nodes er fordi vi konstruerer ressurser sammensatt av data fra kildesystemer som ikke tilordner ID-er til disse konseptene.
Dersom vi skulle konstruert ID-er for disse ressursene må vi bruke mye energi og mange kodelinjer for å holde de ID-ene stabile, for å tilordne de samme ID-ene ved neste eksport fra kildesystemet – da er det mye enklere å konstruerer blank nodes.

Innlasting av data ble gjort graf for graf i form av SPARQL UPDATE-meldinger over HTTP, hver delt i to seksjoner – først sletting av eksisterende tripler i grafen, for så innsetting av nye tripler i samme graf.

Sletting av grafer er en viktig funksjon i vårt tilfelle, da vi ønsker å bytte ut alle tripler fra en eventuell gammel versjon av grafen med tripler fra en ny versjon.
Utskiftingen av hele grafer ønsker vi å gjøre som en atomisk operasjon for å unngå at en graf fremstår som tom før nye data lastes inn.

Serveroppsett

Jeg startet med å kjøre Bigdata i en Jetty-container på en server med 4 GB RAM og 100 GB disk – dbdev01.
Med unntak av lokasjonen til journal-fila (databasen til Bigdata), kjørte jeg med standardinnstillinger og 2 GB Java-heap.

Datamengder

Mot denne lastet jeg inn ca 450K (450.000) grafer.
Dette utgjorde i overkant av 84M (84.000.000) tripler.

Journal-fila vokste til 14 GB.

Ytelse ved innlasting av data

I starten klarte jeg å laste inn ca 10 grafer per sekund.
Det er ikke spesielt imponerende hastighet, men siden dette var en test så lot jeg prosessen fortsette.
Etter ett døgn var hastigheten nede i 2-3 grafer per sekund.
Etter to døgn var hastigheten nede i 1-2 grafer per sekund.

Å gjøre SPARQL-spørringer mot databasen samtidig som importen pågikk var bortimot ubrukelig, selv enkle spørringer som å hente ut navn på 60 ressurser.
Samtidig sakt importhastigheten ned til ca 1 graf per 10 sekunder.

Da var 450.000 grafer importert, 85% av datasettet vårt, som for tiden øker med ca 100.000 grafer per år.
Dette skalerer ikke.
Bestemte meg for å avbryte importen.

Ny server med mer minne

Jeg fikk en ny server til rådighet, med 32 GB RAM og 100 GB disk – dbdev02.
Serveren kjørte allerede noen tjenester, så jeg hadde ca 28 GB RAM ledig.
Ellers var det lite last på serveren.

Jeg kopierte journal-fila på 14GB fra dbdev01 til dbdev02, og starta opp Bigdata på begge servere, samme konfigurasjon, og med 1 GB Java heap.

Ytelsestester spørringer

Gjorde samme tester mot begge serverne.

Test #1

Første spørringen mot serveren er en SPARQL-spørring med datofiltrering og dybde på 5 (Vedlegg 1).
Resultatet fra spørringen er ca 80K (80.000) løsninger, i SPARQL RESULTS XML-format på 75 MB.

Ved kald, nyoppstartet Bigdata var dbdev02 (24s) vesentlig raskere enn dbdev01 (2m31s).

Ved gjentatte utføringer av samme spørring var begge servere nokså like raske, også etter kjøring av andre relativt enklere spørringer i mellomtiden.

Test #2

En annen spørring som ga store utslag var med dybde på 4, uten filtrering og med LIMIT 100.000 (Vedlegg 2).
Resultatet fra spørringen er ca 53K (53.000) løsninger, i SPARQL RESULTS XML-format på 22 MB.
Resultatet var altså mindre enn den angitte begrensningen på 100K.

dbdev02 (1m19s) var mye raskere enn dbdev01 (12m23s).
Dette var med varm database.

Innlasting av data mot 32 GB minne

En ny test av import av data, som inkluderer overskriving av gamle grafer, denne gang gjort mot dbdev02 med 32 GB minne, viser en importhastighet på ca 5 grafer i sekundet.

Analyse av testresultatene

Den største forskjellen er rett etter Bigdata nettopp har starta opp.
Mange av spørringene som ga store utslag etter kald oppstart returnerte omtrent like raskt etter gjentagende spørringer.
Dataene i resultatet blir muligens cachet et sted.

Minne

dbdev01 har etter noen spørringer lite ledig RAM, mens dbdev02 har mye ledig RAM.
Det kan tyde mot at Bigdata har det bedre når mye av datafila ligger i minnet.

Diskytelse

Hjelper nok også om disken er rask.
Virker som at disken er raskere på dbdev02 enn dbdev01.
En test lokalt på hver server viser at kopiering av fil på 1 GB tok 14.5s på dbdev01 og 6.2s på dbdev02.
Ingen prosesser på noen av boksene som bruker nevneverdig mye disk-IO når Bigdata idler.

Swapping

Kanskje swapping på dbdev01 kan være årsak, selv om swap-aktiviteten for tiden er lav.

Munin-graf over minne for dbdev02 viser en økning på 16GB i cache (fil-cache) etter oppstart av Bigdata.
Null swapping.

Munin-graf over minne for dbdev01 er fullstendig mongo, går opp og ned som en jojo i den perioden Bigdata har kjørt (2 dager).
Viser også mye swapping, spesielt under inserts.

Konklusjon

Bigdata trives veldig godt med mye RAM og bruker operativsystemets filcache for å få rask aksess til dataene.

Bigdata feiler ikke like dramatisk som Jena Fuseki TDB når minnet går fullt.
Selv om vi endte opp med å teste Bigdata med mer minne enn vi testet med Jena Fuseki TDB, så taklet Bigdata med 4 GB minne mye større datasett enn Jena Fuseki TDB klarte med det samme.

Det er ikke så viktig med stor Java heap under innlasting av data.
Heap-størrelsen øker når det gjøres spørringer, så større heap har kanskje en positiv effekt ved mange og tunge spørringer.

Den nye innlastingstesten viser at Bigdata er mye raskere på innlasting av data dersom den har nok minne til databasen.

Vedlegg

Vedlegg 1: SPARQL Test #1

SPARQL-spørring som lister ut avspilt musikk i en tidsperiode på én måned:

PREFIX dct: <http://purl.org/dc/terms/>
PREFIX ebuccdm: <http://www.ebu.ch/metadata/ontologies/ebuccdm#>
PREFIX digas: <http://id.nrk.no/2013/digas/class/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT * WHERE {
  GRAPH ?g {
    ?part a digas:Music .
    ?timeline ebuccdm:hasTimelineTrackPart ?part .
    ?prog ebuccdm:hasTimelineTrack ?timeline .
    ?trans ebuccdm:playsOut ?prog .

    ?part dct:title ?partTitle .
    ?prog dct:title ?progTitle .
    ?trans ebuccdm:publicationStartDateTime ?startTime .
    FILTER ( ?startTime >= "2014-01-01T00:00:00+01:00"^^xsd:dateTime ) .
    FILTER ( ?startTime < "2014-02-01T00:00:00+01:00"^^xsd:dateTime ) .
  }
}
ORDER BY ?startTime

Vedlegg 2: SPARQL Test #2

SPARQL-spørring som lister ut medvirkende på programmer med en begrensning på 100.000 resultater:

PREFIX nrk: <http://gluon.nrk.no/dataordbok.xml#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX ebuccdm: <http://www.ebu.ch/metadata/ontologies/ebuccdm#>

SELECT ?obj ?title ?contactName ?roleName
WHERE {
    ?obj a nrk:programme .
    ?obj dct:title ?title .
    ?obj ebuccdm:hasContributor ?contributor .
    ?contributor ebuccdm:contactName ?contactName .
    ?contributor ebuccdm:hasRole ?role .
    ?role ebuccdm:roleName ?roleName .
} LIMIT 100000

At night this tool makes the screen a bit warmer, so your eyes wont “hurt” so much of the otherwise so bright display of your desktop background, browser or editor.

You provide the tool with your approximately geo coordinates and some value for upper and lower limit of color temperature, then it will automatically and continuously change color temperature all through day and night.

Example command for running this tool, if your’re in Norway:

$ redshift -l 60.0:10.0 -t 5700:3600 -g 0.8 -m vidmode -v

Jul  1 23:11:56 lance imapd: LOGIN, user=knut-olav@hoven.ws, ip=[::ffff:AAA.BBB.CCC.DDD], port=[48700], protocol=IMAP
Jul  1 23:11:56 lance imapd: knut-olav@hoven.ws: Permission denied

The solution was pretty simple.

The /tmp folder had bad permissions. This server was only meant for hosting email services, so bad permissions on /tmp folder was actually not an issue earlier.

I guess the wrong permissions were caused by my custom XEN node setup using multiple partitions, including a partition just for /tmp.

Debugging was quite hard

Authentication was successful, as I got a different error message when authenticating with a known bad password.

I debugged it using strace. It wasn’t easy, as courier imap forks out child processes for each connection, which I had to strace as well.

# strace /usr/sbin/couriertcpd -address=0 -maxprocs=40 -maxperip=20 -nodnslookup -noidentlookup 143 /usr/lib/courier/courier/imaplogin /usr/bin/imapd Maildir

Connect to port 143 using telnet.
Log in using this command:

i login MY_EMAIL_USERNAME MY_PASSWORD

Then find the imap process PID. Look for a process running as user vmail:

$ ps axuw|grep imapd
#...
vmail      362  0.0  1.0   4616  1344 ?        S    01:46   0:00 /usr/bin/imapd /var/spool/mail/vmail/hoven.ws/knut-olav/Maildir/
#...

In this case, the PID is 362. Then attach strace to it using strace -p 362, as sudo.

From the telnet interface, I entered a couple of commands like these:

2 select "INBOX"
5 UID fetch 1:10 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)])

Then I found this somewhere down into the strace output:

open("/tmp/tmpfWsezjv", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
write(2, "ERR: knut-olav@hoven.ws: Permiss"..., 43) = 43

Fixing the problem
chmod 1777 /tmp

As I wrote earier… a simple solution.

CSS og Javascript er også programmeringsspråk og bør behandles således.

Kode kjører i forskjellige miljøer, enten det er på en web-server, i en virtuell maskin, en applikasjonsserver, i nettleseren eller instruksjoner som dynamisk bygges opp og sendes til eksekveringsmotorer som gjør en jobb og sender ferdig prosessert data tilbake. Det kan være preprosessorer som ved kompilering skriver om deler av programkoden.

Dette er noe å tenke på når man strukturerer opp prosjektet i kataloger og filer.

Forskjellige programmeringsspråk krever forskjellige strategier

Noe man kanskje ikke tenker så mye på mens man forsøker å konfigurere opp prosjektet til å kjøre Java-testene eller kompilere C-fila, er at en løsning ofte består av flere enn ett programmeringspråk. Om man utvikler web-løsninger er CSS og Javascript blitt en selvfølge. CSS og Javascript er programmeringsspråk og bør behandles således.

Javascript er et nesten like gammelt språk som Java, men det er først de siste årene at tradisjelle utviklere har fått øynene opp for hva som er mulig med Javascript. Desto mer man gjør i Javascript desto større er behovet for å teste funksjonaliteten. Det er fullt mulig å kjøre automatiserte enhetstester mot Javascript-kode, og det finnes verktøy for å detektere typiske feil og påpeke klassiske fallgruver. Det finnes også verktøy for å minifisere Javascript slik at filene blir mindre og legger mindre beslag på båndbredden til brukerne av systemet, og ikke minst like viktig er at det kan spare kostnader ved å senke krav til båndbredde fra systemet. Tilsvarende finnes det verktøy for CSS som minifiserer filene og som kan analysere filene og detektere ineffektive regler og duplikate regler som aldri inntreffer.

Retningslinjer

Mange programmeringsspråk har anbefalinger til hvordan programkode skal struktureres. Om systemet som skal lages hovedsaklig skal skrives i ett programmeringsspråk kan man følge dette språkets retningslinjer. I retningslinjene defineres gjerne hva en typisk fil skal inneholde, navngiving, indentering, kontrollkode, feilhåndtering, hvordan filene plasseres i en katalogstruktur og mye annet. Perl-prosjekter struktureres ofte etter CPAN sine retningslinjer, PHP-prosjekter struktureres ofte etter PEAR sine retningslinjer og Java har sine retningslinjer.

En by bygger seg ikke selv. Foto: Flickr/Science Museum London (CC)

Det har de siste årene blitt populært å bruke Maven som kontrollsystem for prosjekter, spesielt for Java-prosjekter, men kan også brukes til andre programmeringsspråk som PHP og Javascript. Man bruker gjerne Maven som en innpakking av prosjektet, til bygging av systemet, kjøre tester, pakketere og rulle ut nye versjoner. Det legger ingen føringer for hvordan man strukturerer innholdet av filer i prosjektet.

Det er ingen fasit når det kommer til struktur av prosjekter, men dersom man er flere som arbeider på samme prosjekt kan det være smart å bli enige om hvilke retningslinjer man skal følge.

Ikke all kode er programkode

Tester skal støtte oppunder løsningen og gi en god og stabil leveranse.

Den viktigste delen av løsningen er det kjørbare systemet, og det er dette som skal gi merverdi til bedriften. Dokumentasjon, tester, byggerammeverk og utviklingsmiljø er biprodukter; støttefunksjoner som skal bidra til å gi et godt og kjørende system.

Maven brukes, som nevnt ovenfor, gjerne til bygging av løsningen og til å kjøre opp web-server under utvikling, men Maven er ikke en del av det kjørbare systemet i leveransen.

Tester, som enhetstester og funksjonstester, er ikke programkode og trenger ikke behandles som det. Tester skal støtte oppunder løsningen og gi en god og stabil leveranse. Tester bør holdes utenfor katalogstrukturen til programkoden. Det kan være løsere retningslinjer til testene, for eksempel friere navngiving av tester, ingen maksimal linjelengde eller flatere katalogstruktur.

Testene dine er viktige fordet!

En god test er en verifikator om at en funksjon fungerer. En god test er presis på hva den tester og er lett å lese og forstå.

En god praksis er å navngi testene etter hva de tester. Et eksempel kan være en test som skal teste at en kunde som heter “Ola” har adresse “Drammensveien”, og denne testen kan da hete test_kunden_ola_har_adresse_drammensveien, selv om dette ikke stemmer overens med for eksempel Java’s camelcase.

En testfunksjon skal teste en ting, og kun én ting. Du trenger ikke å teste at du har korrekt brukernavn og passord i konfigurasjonen for hver eneste test du skriver. Hvis navnet på testen indikerer at en brukers adresse skal kontrolleres så skal testen gjøre det, og lite annet. Samme testen kan gjerne teste forskjellig input dersom det virker hensiktsmessig. For eksempel kan en e-postadresse-validator kontrollere flere godkjente e-postadresser, men kanskje bør det være en egen testfunksjon for verdier som skal feile valideringen.

Samhandling med andre arkitekturprinsipper

Det er mulig å kombinere struktur på utviklingsmiljøet med andre arkitekturvalg. For enkle web-løsninger er trelagsarkitekturen MVC (model-view-controller) populær, hvor man skiller applikasjonslogikk fra datamodell og presentasjon, og man kan plasserer filer i en katalog navngitt etter laget hvor de hører hjemme.

Hvis prosjektet setter domenedrevet design høyt så kan det være smart å segmentere ut filene som utgjør domenemodellene i egne kataloger, for å holde domenet samlet uten for mye støy fra annen kode.

En felles hverdag

Det er smart å ha orden i prosjektet sitt. Kildekoden til prosjektet kan sees på som skrivebordet ditt; hvis det er vanskelig å finne det du leter etter så er ikke arbeidsmiljøet optimalt. I et prosjekt med mange utviklere betyr dette at alle deler “felles skrivebord”. Å sette retningslinjer som alle i prosjektgruppen enes om å følge kan bidra til en ryddigere hverdag for alle, men retningslinjene bør ikke blir detaljerende og vanskelige å følge. Alle skal føle seg komfortable med disse.

Det er en felles hverdag. En god struktur bidrar til raskere utvikling, enklere feilsøking, og etterhvert til bedre kode med færre feil.

Puslespill (Puzzle). Foto: Flickr/create_joy (CC)

Utenfra fungerer en modul som en sort boks; man gir beskjeder inn og man får svar tilbake. Man vet ikke hvordan den sorte boksen kommer frem til svaret. Det gjør det enklere å forholde seg til støttefunksjoner, så man kan fokusere på den funksjonaliteten man skal lage. Jeg kaller det støttefunksjoner fordi disse funksjonene ikke er viktige; eller rettere sagt så er funksjonaliteten man arbeider med for øyeblikket mye viktigere enn en hvilken som helst annen annen modul.

Vedlikeholdbarhet

Behovet for modulbasert arkitektur oppstår når systemer blir for store til at én eller to personer kan ha oversikt over hele systemet. Da blir det viktig med vedlikeholdbare moduler av håndterbare mengder med kode.

Vedlikeholdbarhet betyr ikke at koden til stadighet må endres, noe som faktisk fungerer mot sin hensikt. Dersom modulen endres for ofte med for store endringer kan det innføre feil. Mye ny funksjonalitet kan gjøre modulen uoversiktlig og mindre vedlikeholdbar. En vedlikeholdbar modul bidrar til at resten av systemet får en tydelig måte å kommunisere med modulen på, og dersom man støter på feil så skal man klare å fikse feilen.

Eksempel på modulbasert løsning

Et svært enkelt og overordnet eksempel på en modulbasert nettbutikkløsning

Kjernen av MyWebShop kommuniserer mot eksterne komponenter over definerte grensesnitt. Det er ikke sikkert at alle komponenter har grensesnitt basert på åpne standarder, som SQL, SMTP og HTTP. Det kan være behov for å definere nye grensesnitt i bedriften. For eksempel kan kommunikasjon mot et CMS-system skje via et nytt grensesnitt vi kaller ProductService som tilbyr funksjoner som er nyttige for vår nettbutikk. På denne måten definerer vi tydelig hvilke funksjoner nettbutikken har behov for, samtidig som vi skjuler andre funksjoner som CMS-systemet tilbyr som ikke er viktige for vårt system.

Når kommunikasjon mellom moduler foregår over definerte grensesnitt, så kan moduler byttes ut med ny moduler ved behov. For eksempel kan modulen My Simple CMS byttes ut med et mer avansert og bedre CMS-system dersom nettbutikken vår blir større og får nye behov som den gamle modulen ikke kan tilby. Om den nye modulen ikke støtter det samme grensesnittet som den gamle kan man lage et veldig lite oversettingslag, kalt for et adapter, som oversetter mellom vårt eget ProductService-grensesnitt og den nye modulen.

Samhandling

Et ofte brukt tilfelle av modulbasert programvare er når data skal behandles i flere ledd. Samme grensesnitt kan brukes i front av flere forskjellige moduler. For eksempel kan et spamfilter kobles på foran e-posttjeneren slik at e-post kan filtreres før det lagres i brukerens innboks, og uønsket e-post kastes uten at brukeren ser e-posten. Fordelen med modulbasert arkitektur er klar, man får et mer oversiktlig system med komponenter som kan settes sammen og byttes ut ved behov.

Et IT-system skal løse et behov for virksomheten, eller kunden som vi kaller det. Kunden har mange behov, men man avgrenser gjerne systemet til å løse et subsett av disse behovene. Vi kaller dette for problemdomenet.

Målet med logisk arkitektur er å styrke de funksjonelle kravene, og veien til en god logisk arkitektur kan være lang. Kunden vet ikke hva det egentlige behovet er, og har ofte sin en oppfatning om hvordan løsningen skal se ut. Utviklere blir ofte veldig engasjerte og starter å lage noe de selv synes virker kult istedenfor å grave og analysere i kundens egentlige problemer.

South Park Gnomes plan

Verktøy

Det finnes flere verktøy for å analysere seg fram til en god logisk arkitektur. For å definere de funksjonelle kravene kan man skrive brukstilfeller (use cases på engelsk) som definerer hvilke brukere eller roller som skal utføre hvilke steg i en prosess for å ende opp med et ønsket resultat. Dette avdekker alternative valg som brukeren kan gjøre, for eksempel hva som skjer hvis brukeren taster en ugyldig verdi inn til systemet eller avbryter midt i prosessen. Dette dokumentet brukes for å måle om funksjonaliteten som ble avtalt er implementert og fungerer. Dette skaper en målbarhet som er viktig for at både kunde og leverandør (prosjektgruppen) skal ha felles forståelse for hva som lages og hva som er levert.

Det finnes også verktøy for å visualisere systemer, og UML er en notasjon for å visualisere systemer. Det kan visualisere brukstilfeller, flyt av data og koblinger mellom komponenter, valgmuligheter underveis i prosesser og tilstand til komponenter under gitte kriterier. Det finnes flere aspekter man kan visualiere med UML, men de nevnte er hovedsaklig de viktigste innenfor logisk arkitektur. Det handler om å modellere domenet, og komponentene navngis ofte etter begreper som brukes i virksomheten.

Domenedrevet design

En teknikk som jeg har fått sansen for er domenedrevet design (DDD), hvor fokuset rettes mot problemdomenet og det viktigste er å ha en god og dyp domenemodell på et felles språk. Dyp i at den reflekterer virksomhetens problemområde best mulig og med felles språk på tvers av programkode og de daglige funksjoner i virksomheten.

For å skape et felles språk som alle i prosjektet kjenner til og forstår betydningen av, så bør man lage en ordbok som alle gjør seg kjent med. Alle begreper fra domenemodellen bør legges inn i en slik ordbok. Ordboken skal være fri for systemtekniske begreper og skal forstås av domeneekspertene; de som kjenner virksomhetens funksjoner best.

Eksempel på domenemodell

Nedenfor vises et eksempel på en domenemodell av et bloggsystem. Det anbefales å skrive en kort tekst til figurene, da det ikke alltid er lett å forstå meningen bak en tegning. Dette er bare én av mange måter å visualisere et problem på.

Eksempel på domenemodell for en blogg

Når man får dypere forståelse av domenet lager man en ny tegning som enten erstatter en gammel tegning eller som kan supplere en eksisterende tegning. Dersom kunden fra eksempelet over også ønsker at leserne skal kunne abonnere på en strøm av blogginnlegg, så kan man lage en ny tegning som viser et søk som mates inn i en nyhetsstrømgenerator (i mangel av bedre ord).

Det finnes ingen fasit på logisk arkitektur. Alle konkurransedrevne virksomheter har særegne behov, noe de trenger for å kunne konkurrere og skille seg ut i markedet. Nettopp derfor er logisk arkitektur trolig det vanskeligste å forstå og gjennomføre innenfor IT-arkitektur.

Lykke til med neste prosjekt! Etter å ha lest dette setter du deg selvfølgelig dypere inn i kundens virksomhet og avgrenser systemets oppgaver til å løse kundens konkrete problem – ikke sant?

Om å skape orden

Arkitektur er teknikker som skal hjelpe mennesker til å forstå kompliserte systemer, som igjen skal få kompliserte systemer til å virke bedre sammen, være raske, mer feiltolerante og enkle å bruke. Resultatet skal bli et enklere system. Det strømlinjeformer enkelte prosesser av systemene og skal hjelpe til med å gjøre systemene mer vedlikeholdbare.

Det er flere måter å komme fram til en arkitektur. Jeg har selv gått i fella, flere ganger – man velger en arkitektur for tidlig i prosjektet. Det er lett å gå seg blind i arkitektur når man hører at man trenger ting som Scrum, MVC, Cloud Computing, skyen, SaaS, SOA og ESB, buzzwords brukt av selgere for å selge inn produkter og tjenester. Løsningen er å ikke låse seg til en arkitektur til å begynne med, før man egentlig vet hva man skal lage.

En arkitektur utvikler seg over tid mens man arbeider målrettet med prosjektet og målrettet jobbet mot målet med prosjektet er. Det er alltid en smartere måte å løse et problem på, man bare vet ikke om det ennå.

Evolusjon (evolution) Foto: Flickr/Esthr (CC)

Innfallsvinkler

Arkitektur finnes på flere nivåer. Man ser på arkitektur fra forskjellige innfallsvinkler. Som utvikler tenker jeg gjerne på hvordan koden er strukturert, gjerne i moduler strukturert i hver sine kataloger, på objekter med arv av abstrakte klasser og grensesnitt og hvordan kommunikasjonen mellom to systemer på nettverket skal foregå. En driftsperson tenker mer i retning av hvilke servere tjenestene skal kjøre på, i hvilke nettverkssoner, regelsett i lastbalanserer, feilhåndtering og backup. Ledelsen ønsker gjerne at utviklingsteamet skal være agile og kunne snu seg raskt ved endringer, men man ønsker også stabilitet og forutsigbarhet. En optimal arkitektur koster mye, ofte mer enn man er villig til å investere i prosjektet.

Wikipedia nevner følgende innfallsvinkler til arkitektur:

• Funksjonell og logisk
• Programkode og modulbasert
• Utvikling og strukturelt
• Kjøremiljø, samtidighet, prosesser og tråder
• Komponenter, fysisk utplassering, utrulling og installering
• Brukerinteraksjon og tilbakemeldinger
• Data og datamodell

Jeg vil igjennom en serie med innlegg berøre disse arkitekturtemaene nærmere.

Dersom du bare er interessert i å lese om arkitektur kan du følge arkitekturfeeden.