Spring Boot Canary Releases Sinhala Tutorial | Microservices Deployment Guide

Spring Boot with Canary Releases: ඔබේ Deployments ආරක්ෂා කරගමු! | Sinhala Guide

Software development ලෝකයේ අපි හැමෝම හොයන්නේ ඉක්මනින්, ආරක්ෂිතව සහ විශ්වාසදායක විදිහට අපේ applications production එකට deploy කරන එක නේද? අලුත් feature එකක් හරි bug fix එකක් හරි deploy කරලා, ඒකෙන් production එකේ ලොකු අවුලක් වෙනවා දකින එක තරම් භයානක දෙයක් තවත් නෑ. එහෙම වෙලාවට තමයි Canary Releases වගේ deployment strategies අපිට උදව් කරන්නේ.

අද අපි මේ article එකෙන් බලමු Spring Boot applications වලට Canary Releases කියන concept එක apply කරන්නේ කොහොමද කියලා. මොකක්ද මේ Canary Release එකක් කියන්නේ? ඒකෙන් ලැබෙන වාසි මොනවද? වගේම, සරල Spring Boot application එකක් අරගෙන කොහොමද Canary deployment එකක් simulate කරන්නේ කියලත් අපි බලමු. එහෙනම්, අපි පටන් ගමු!

Canary Releases කියන්නේ මොකක්ද?

ඉතින්, Canary Release කියන්නේ අලුත් version එකක් deploy කරන ආරක්ෂිත ක්‍රමයක්. මේ ක්‍රමයේදී අපි අලුත් application version එකක් මුලින්ම deploy කරන්නේ user base එකේ පොඩි කොටසකට විතරයි. (උදාහරණයක් විදිහට, users ලා 5% කට විතර) හරියට ගල් අඟුරු පතල් වල කැනරි කුරුල්ලෝ යොදාගෙන වායු විෂ තත්වය (toxic gas) චෙක් කරා වගේ, අපේ අලුත් code එකේ අවුල් තියෙනවද කියලා බලන්න පොඩි user පිරිසක් යොදාගන්නවා.

මේ පොඩි user පිරිසට අලුත් version එක පෙන්වලා, ඒකේ performance එක, errors, user feedback වගේ දේවල් අපි හොඳට monitor කරනවා. හැමදේම හොඳින් සිද්ධ වෙනවා නම්, ඊට පස්සේ අපි ටිකෙන් ටික අලුත් version එකට යන traffic ප්‍රමාණය වැඩි කරනවා. ඒ කියන්නේ, 5% ඉඳන් 20% ට, ඊට පස්සේ 50% ට, අන්තිමට 100% ටම අලුත් version එකට users ලා redirect කරනවා. මේක තමයි gradual rollout කියන්නේ.

යම්කිසි අවස්ථාවක අලුත් version එකේ ප්‍රශ්නයක් මතුවුණොත්, අපි ඉක්මනින්ම traffic එක ආපහු පරණ, stable version එකට හරවනවා. මේකට rollback එකක් කියලා කියනවා. මේ නිසා, ලොකු user base එකකට එකපාරටම බලපාන ලොකු අවුලක් ඇතිවෙන එක වළක්වා ගන්න පුළුවන්.

වෙනත් Deployment Strategies එක්ක සංසන්දනය කරමු (Comparison with Other Deployment Strategies)

• Blue/Green Deployment: මේකේදී අපි Production එකේදී අලුත් version එක වෙනම environment එකක (Green) deploy කරනවා. පරණ version එක තියෙන environment එක (Blue) තවමත් run වෙනවා. අලුත් version එක හොඳයි කියලා තහවුරු වුණාම, අපි traffic එක එකපාරටම Blue එකේ ඉඳන් Green එකට switch කරනවා. මේක Canary Releases වලට වඩා ඉක්මන් වුණත්, එකපාරටම traffic switch කරන නිසා අවදානම වැඩියි.
• Rolling Updates: මේකේදී අපි application instances එකින් එක අලුත් version එකට update කරනවා. Traffic එක ක්‍රමයෙන් අලුත් instances වලට යනවා. මේක Canary වලට ටිකක් සමානයි, හැබැයි Canary එකේදී අපිට traffic split එක පාලනය කරන්න පුළුවන්.

Spring Boot Application එකකට Canary Release එකක් ගෙන එන්නේ කොහොමද?

Spring Boot කියන්නේ Microservices වගේ architecture patterns වලට ඉතාම හොඳ platform එකක්. Canary Releases වලට අවශ්‍ය core concept එක තමයි traffic routing. ඒ කියන්නේ, අපිට පුළුවන් වෙන්න ඕනේ different versions වලට traffic එක වෙනස් විදිහට යොමු කරන්න.

මේකට සාමාන්‍යයෙන් අපිට load balancers, API gateways, service meshes (like Istio, Linkerd) වගේ tools අවශ්‍ය වෙනවා. මේවා තමයි අපේ client requests අදාළ application version එකට හරවන්නේ.

අපි මේකට ප්‍රධාන වශයෙන්ම focus කරන්න ඕනේ කරුණු කීපයක් තියෙනවා:

1. Multiple Versions of the Application: අපේ application එකේ පරණ stable version එකත්, අලුත් canary version එකත් දෙකම එකපාර run වෙන්න ඕනේ.
2. Traffic Router: මේ දෙක අතර traffic බෙදන්න load balancer එකක් හෝ API gateway එකක් අවශ්‍යයි. මේක Kubernetes, AWS ALB, Nginx, Istio වගේ platform එකක් වෙන්න පුළුවන්.
3. Monitoring and Metrics: Canary version එකේ performance, errors, response times වගේ දේවල් නිරන්තරයෙන් monitor කරන්න ඕනේ. Prometheus, Grafana, ELK stack වගේ tools මේකට උදව් වෙනවා.
4. Rollback Mechanism: ප්‍රශ්නයක් ආවොත් ඉක්මනින්ම traffic එක පරණ version එකට හරවන්න පුළුවන් වෙන්න ඕනේ.

Canary Release එකක් Simulate කරමු!

හරි, දැන් අපි theory ඇති කියලා හිතනවා. අපි දැන් පොඩි Spring Boot applications දෙකක් හදලා, කොහොමද මේ Canary Release concept එක වැඩ කරන්නේ කියලා බලමු. මේක අපි production environment එකක කරනවා වගේම complex එකක් නෙවෙයි, හැබැයි concept එක පැහැදිලි කරගන්න හොඳ simulation එකක් වෙයි.

අපේ Spring Boot Applications හදමු (Let's Create Our Spring Boot Applications)

අපි Spring Boot applications දෙකක් හදමු. එකක් අපේ පරණ version (V1), අනිත් එක අලුත් version (V2). V2 එකේ පොඩි වෙනසක් කරමු, එතකොට අපිට traffic එකේ වෙනස තේරෙනවා.

Spring Boot Project එකක් හදමු:

spring initializer (start.spring.io) එකට ගිහින්, dependencies විදිහට Spring Web එකතු කරලා project එකක් generate කරගන්න. Java 17+ සහ Maven හෝ Gradle use කරන්න.

SpringBootCanaryV1Application.java (පරණ Version - V1)

මේක තමයි අපේ stable version එක. application.properties එකේ server.port=8080 කියලා දාගමු.

package com.example.canaryv1;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class SpringBootCanaryV1Application {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootCanaryV1Application.class, args);
    }

    @GetMapping("/api/hello")
    public String hello() {
        return "Hello from Canary V1! This is the stable version.";
    }
}

SpringBootCanaryV2Application.java (අලුත් Version - V2)

මේක තමයි අපේ canary version එක. මේකේ application.properties එකේ server.port=8081 කියලා දාගමු. V1 එකට වඩා පොඩි වෙනසක් response එකට එකතු කරමු.

package com.example.canaryv2;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class SpringBootCanaryV2Application {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootCanaryV2Application.class, args);
    }

    @GetMapping("/api/hello")
    public String hello() {
        return "Hello from Canary V2! We just updated the greeting message. Enjoy!";
    }
}

Applications Run කරමු (Let's Run the Applications)

දැන් ඔයාට පුළුවන් මේ applications දෙකම වෙන වෙනම run කරන්න.

1. V1 Run කරන්න: ඔයාගේ IDE එකෙන් හරි, terminal එකෙන් mvn spring-boot:run (Maven නම්) හෝ ./gradlew bootRun (Gradle නම්) කියලා command එක දෙන්න. (Make sure you are in the V1 project directory)
2. V2 Run කරන්න: වෙනම terminal එකක් open කරලා, V2 project directory එකට ගිහින් V1 run කරපු විදිහටම run කරන්න.

දැන් ඔයාට පුළුවන් මේවා වෙන වෙනම access කරන්න:

• V1: http://localhost:8080/api/hello
• V2: http://localhost:8081/api/hello

Output එකේ වෙනස පේනවා නේද? V1 එකෙන් "Hello from Canary V1! This is the stable version." කියලා එද්දී, V2 එකෙන් "Hello from Canary V2! We just updated the greeting message. Enjoy!" කියලා එනවා.

Traffic Routing Simulate කරමු (Let's Simulate Traffic Routing)

සැබෑ production environment එකකදී, ඔයාට load balancer එකක් (Nginx, HAProxy) හෝ service mesh එකක් (Istio, Linkerd) තියෙනවා traffic split කරන්න. සරලව තේරුම් ගන්න අපි මෙහෙම හිතමු:

Load Balancer එකකදී අපි rules හදනවා. උදාහරණයක් විදිහට:

• Users ලා 90% කට http://localhost:8080 (V1) ට යොමු කරන්න.
• Users ලා 10% කට http://localhost:8081 (V2) ට යොමු කරන්න.

මේක අතින් simulate කරන්න අපිට කරන්න පුළුවන් දේ තමයි, curl command එක කිහිප වතාවක් run කරලා, response එක මොකක්ද කියලා බලන එක.

Actual Load Balancer Example (Conceptual):

ඔයාට පුළුවන් Nginx වගේ load balancer එකක් භාවිතා කරන්න. Nginx configuration එකක් මෙහෙම හදාගන්න පුළුවන් (concept එකට විතරයි):

# Nginx configuration snippet (conceptual for canary)
http {
    upstream myapp {
        server localhost:8080 weight=90; # V1 - 90% traffic
        server localhost:8081 weight=10; # V2 - 10% traffic
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp/api/hello;
        }
    }
}

මේ Nginx server එක run කරලා, ඔයා http://localhost/ එකට requests යැව්වොත්, ඒ requests 90% ක් V1 එකටත්, 10% ක් V2 එකටත් යනවා. හැබැයි මේක setup කරන එක මේ tutorial එකට ටිකක් විතර complex නිසා, අපි concept එක focus කරමු.

Simulation with Manual Calls:

ඔබට පුළුවන් curl හෝ ඔබේ browser එක භාවිතයෙන් requests යවලා V1 සහ V2 දෙකෙන්ම responses ලැබෙනවාද කියලා බලන්න. මේකෙන් අපිට simulate කරන්න පුළුවන්, load balancer එකක් ක්‍රියා කරන ආකාරය සහ user traffic එක split වන ආකාරය.

මුලින්ම V1 එකට request එකක් යවමු:

curl http://localhost:8080/api/hello

Output:

Hello from Canary V1! This is the stable version.

දැන් V2 එකට request එකක් යවමු:

curl http://localhost:8081/api/hello

Output:

Hello from Canary V2! We just updated the greeting message. Enjoy!

දැන් හිතන්න, අපේ load balancer එකකින් http://localhost/api/hello වගේ endpoint එකකට request එකක් ආවොත්, ඒක V1 ට හරි V2 ට හරි යොමු කරනවා කියලා. අපිට පුළුවන් එක දිගට requests යවලා බලන්න, මොන version එකෙන්ද response එක එන්නේ කියලා. සැබෑ canary deployment එකකදී, මේ traffic split එක automate වෙනවා.

V2 එකේ performance, errors ගැන හොඳට monitor කරලා, හැමදේම හොඳයි නම්, load balancer configuration එක modify කරලා V2 එකට යන traffic percentage එක ටිකෙන් ටික වැඩි කරන්න පුළුවන්. උදාහරණයක් විදිහට, 10% ඉඳන් 25% ට, ඊට පස්සේ 50% ට වගේ.

වැදගත් කරුණු (Important Considerations)

Canary Releases සාර්ථකව ක්‍රියාත්මක කරන්න නම්, තවත් කරුණු කීපයක් ගැන අවධානය යොමු කරන්න ඕනේ:

1. Monitoring and Alerting: Canary version එකේ performance, error rates, latencies, resource usage වගේ දේවල් හොඳින් monitor කරන්න ඕනේ. යම්කිසි දර්ශකයක් (metric) අනතුරුදායක මට්ටමකට ගියොත්, ඒ ගැන alert කරන්න automated systems තියෙන්න ඕනේ. Prometheus, Grafana, Splunk, ELK stack (Elasticsearch, Logstash, Kibana) වගේ tools මේකට උදව් වෙනවා.
2. Automated Rollback: යම්කිසි අවුලක් මතුවුණොත්, manual intervention නැතුව ස්වයංක්‍රීයවම traffic එක පරණ stable version එකට හරවන්න (rollback) පුළුවන් system එකක් තියෙන එක ඉතා වැදගත්.
3. Database Schema Changes: අලුත් version එකේ database schema changes තියෙනවා නම්, ඒ changes backward-compatible වෙන්න ඕනේ. ඒ කියන්නේ, පරණ version එකටත් අලුත් database schema එකත් එක්ක වැඩ කරන්න පුළුවන් වෙන්න ඕනේ. මේක ඉතාම සංකීර්ණ මාතෘකාවක්.
4. Session Management: Users ලාට එකම session එක ඇතුලේ version දෙකක් අතර switch වෙන්න බැරි වෙන්න ඕනේ. Sticky sessions වගේ mechanisms මේකට උදව් වෙනවා.
5. Feature Flags: සමහර වෙලාවට අපිට ඕනේ අලුත් feature එකක් මුලින්ම පෙන්වන්න පුළුවන් users ලා කීප දෙනෙකුට විතරයි. මේකට Feature Flags (feature toggles) use කරන්න පුළුවන්. ඒක Canary Releases වලට අමතරව තවත් ආරක්ෂිත ක්‍රමයක්.

අවසන් වශයෙන් (Conclusion)

ඉතින්, අද අපි Spring Boot applications එක්ක Canary Releases deploy කරන්නේ කොහොමද කියන concept එක ගැන හොඳට කතා කළා. Canary Releases කියන්නේ production environment එකේ අවදානම අඩු කරගෙන, විශ්වාසදායක විදිහට අලුත් features deploy කරන්න පුළුවන් powerful strategy එකක්.

මේකෙන් ඔයාට අවස්ථාව ලැබෙනවා අලුත් code changes සැබෑ users ලාට deploy කරන්න කලින් ඒකේ හැසිරීම (behavior) පරීක්ෂා කරලා බලන්න. ප්‍රශ්නයක් ආවොත් ඉක්මනින්ම rollback කරන්න තියෙන හැකියාව නිසා, ඔයාගේ application එකේ downtime අවම කරගන්නත් පුළුවන්.

මේ article එක ඔයාට ප්‍රයෝජනවත් වෙන්න ඇති කියලා මම හිතනවා. ඔයාගේ next Spring Boot project එකේදී මේ Canary Release strategy එක implement කරලා බලන්න. ඒ වගේම, මේ ගැන ඔයාට තියෙන අත්දැකීම්, ප්‍රශ්න හරි අදහස් හරි පහළින් comment කරන්න!

තවත් අලුත් දෙයක් එක්ක නැවත හමුවෙමු!