Datan eheyden hallinta virhetilanteissa mikropalveluarkkitehtuurissa

Abstract

Työssä tutkitaan virhetilanteiden hallintaa, sekä vikatilanteista palautumista mikropalveluarkkitehtuurissa. Verrattuna monoliittiseen arkkitehtuuriin, mikropalvelut tuovat omat haasteensa vikatilanteiden käsittelyssä hajautetun rakenteen ja itsenäisten palveluiden myötä. Tavoitteena on löytää ratkaisuja siihen, miten näistä tilanteista selvitään ilman suurempia häiriötä ohjelman muussa toiminnassa tai datassa. Työssä vertaillaan muutamaa erilaista ratkaisuvaihtoehtoja, sekä arvioidaan niiden toteutuskelpoisuutta ja suorituskykyä virheiden hallinnassa olemassa olevassa järjestelmässä.

Testaus suoritetaan työn teettäjän, Pinja Oy:n, ohjelmistotuotteella. Se on rakennettu mikropalveluarkkitehtuurimaisesti varsinkin datan osalta ja siten soveltuen arkkitehtuurinsa puolesta hyvin virhetilanteiden testaukseen. Ohjelmassa mikropalvelut lähettävät viestejä usean palvelun välillä ja muokkaavat dataa vastuualueittain, jolloin virhetilanteet yhdessä palvelussa voivat aiheuttaa epäloogisia tilanteita juuri datan välillä.

Ratkaisuvaihtoehtoina kokeillaan saaga-operaatiot –mallia sekä kaksivaiheista kommitointia. Suurimmat erot näillä kahdella ratkaisulla on siinä, miten data on käytettävissä muiden operaatioiden osalta suorituksen eri vaiheissa. Kaksivaiheinen kommitointi takaa vahvan eristyneisyyden, eli operaation aikana muut operaatiot eivät pääse käsiksi käsiteltävään dataan, ja operaation jälkeen data on joko eheässä tilassa tai virheen sattuessa se on alkutilassa. Saaga-operaatiot korjaavat virheet sen sijaan käänteisillä operaatioilla jo suoritetuille muutoksille. Siten virheellinen data voi olla hetken aikaa muiden operaatioiden käytettävissä. Saaga-operaatiot eivät aseta kuitenkaan järjestelmälle rajoitteita tiettyihin teknologiavalintoihin, kun taas kaksivaiheinen kommitointi toimii vain tietyillä tietokannoilla ja muilla teknologioilla.

Näitä ratkaisuvaihtoehtoja kokeiltiin testijärjestelmässä, missä saaga-operaatiot osoittautuivat selvästi toteutuskelpoisemmaksi vaihtoehdoksi. Vaikka ne vaativat osaltaan lisää työtä korvaavien operaatioiden toteuttamiseen, soveltuvat ne hyvin yhteen mikropalveluiden kanssa. Kaksivaiheista kommitointia ei päästy teoriaosuutta pidemmälle testeissä, koska sitä ei tueta ohjelmistokehyksen osalta. Vaikka tulevaisuudessa se voi tulla mahdolliseksi, on se siitä huolimatta mikropalveluiden olemuksen vuoksi ongelmallinen. Rajoitteiden lisäksi kaksivaiheinen kommitointi sitoo palveluita tiukasti yhteen, jolloin mikropalveluiden itsenäinen kehittäminen monimutkaistuu. Kuitenkin, jos järjestelmältä vaaditaan vahvaa eristyneisyyttä, eikä kaksivaiheinen kommitointi ole käytössä, jää jäljelle palveluiden suunnitteleminen siten, että yhdessä palvelussa toteutetaan kaikki eristyneisyyttä vaativat dataoperaatiot. Siten hajautettuja operaatioita ei muodostu, eikä näiden virheiden hallintaa ole tarpeellista toteuttaa.

This thesis focuses on a microservice architecture and examines how data integrity can be preserved throughout different kind of system or business logic errors. In comparison to a more traditional monolithic architecture, microservices have their own challenges when dealing with failures. This is mainly caused by the nature of microservices as a result of their independent services and distributed structure. The main objective is to find solutions on how to handle these errors or faults without losing data integrity or facing other major disturbances. For this we compare a few different solutions and analyze whether they are feasible in an existing software.

The testing is done in a manufacturing execution system software, which is owned by Pinja Oy. The software is built with microservice architecture in mind especially in terms of data, thereby it’s suitable for data integrity testing in faults. In the software, the microservices are sending messages between multiple different services and modifying data within their own area of responsibility, which means errors in one service can lead to incoherent situations between data.

As solutions we test saga operations as well as two-phase commits. The central differences regarding data between these two are on how the data is available to other operations during this period. Two phase commit ensures strong isolation which means that the other operations can’t access the same data at the same time. Following this, by the end of the two-phase commit the data integrity is preserved either by a successful operation or a rollback in failures. Saga operations in return fix the data faults with compensating transactions for the already executed operations. Thus, the incorrect data is available for the other operations for a short while. However, saga operations don’t have any specific constraints for the system, whereas two-phase commit works only with certain databases and other technologies.

These solutions were tested in the test system, where saga operations evidently turned out to be the more feasible choice. Although they require more implementing with their compensating transactions, they translate well to work with microservices. Two-phase commit couldn’t be tested further than the theory section, as it isn’t supported by the framework the software uses. Even though in the future it could become a real possibility, it’s still a bit problematic when dealing with microservices. Along with the restrictions, the two-phase commit ties services strongly together, which in turn complicates the independent development of the microservices. Nevertheless, if strong isolation is required from the system and two-phase commits are not available, leaves that us rather few options. We could architect the services so that all the data operations needing strong isolation for a one operation are situated within one service. In that way, distributed operations are not formed, and the need for a distributed transaction management is no longer a requisite.