[DEV] J-Jay

예외(Exception)

J-Jay — Sat, 1 Jun 2024 21:55:47 +0900

예외(Exception)

프로그램 실행시, 어떤 원인으로 인해 비정상적인 동작을 일으키며 프로그램이 종료되는 상황이 일어 났을때

대부분 사람들은 프로그램이 오류가 발생했다고 생각한다. ~~(어떤 오류인지는 관심 없다)~~

하지만 나는 개발자니까 개발자 기준에서,

오류는 크게 두가지 종류가 있다. 컴파일 할 때 발생할 수 있는 컴파일 에러, 실행 중 발생되는 런타임 에러

컴파일 에러는 우리가 잡기가 쉽지만~~(코딩할떄 나오니까)~~ 런타임 오류는 실행 중에 발생하기에 잡기가 어렵다.

그래서 여기선 런타임 에러에 대해서 깊게 살펴보겠다.

런타임 에러

Java에서 런타임 오류는 두종류로 보고있다. 에러(Error)와 예외(Exception)

이 두개의 차이를 알아보자.

에러는 프로그램이 코드로 복구될 수 없는 오류를 의미하고, 예외는 프로그래머가 직접 예측하여 막을 수 있는 처리가능한 오류이다.

예외 처리

예외처리란 말 그대로 예외가 발생했을때 어떤 동작을 처리해야하는지를 말한다.

예외처리의 종류는 아래와 같다.

try ~ catch ~ finally
예외가 발생했을때 위의 키워드로 예외 처리를 할 수 있다.
여기서 중요한 점은 모든 예외는 Exception 클래스를 상속 받는다.

throws

예외처리는 위와 같이 try ~ catch문으로 처리할 수도 있지만 아래처럼 예외 처리를 다른 곳으로 넘길 수도 있다.

public static void divide(int a,int b) throws ArithmeticException {
	if(b==0) throw new ArithmeticException("몫이 0이면 안됩니다.");
	int c=a/b;
	System.out.println(c);
}

public static void main(String[] args){
	int a=10;
	int b=0;
		
	divide(a,b);
}

내부 클래스(Inner Class)

J-Jay — Sat, 1 Jun 2024 21:22:43 +0900

내부 클래스 (Inner Class)

내부 클래스(inner class)란 하나의 클래스 내부에 선언된 또 다른 클래스를 의미한다.

보통 사용자 클래스 자료형이 필요하면, 메인 클래스 외부에 선언하거나, 따로 독립적인 클래스 파일을 만들어 불러와 사용해 왔다.

내부 클래스는 내부에 정의된다는 점을 제외하고는 일반적인 클래스와 다르지 않다. 우리가 어느 클래스에 변수나 상수가 필요하다면 클래스 멤버로서 클래스 내에서 선언하여 사용해 왔듯이, 선언 주체를 변수에서 클래스로 바꾼다면 그것이 내부 클래스인 것이다. 이처럼 내부 클래스는 보통 두 클래스가 서로 긴밀한 관계가 있거나, 하나의 클래스또는 메소드에서만 사용되는 클래스일 때 이용되는 기법이라고 보면 된다.

※ 내부(inner) 클래스는 중첩(nested) 클래스로 분류되기도 한다.

내부 클래스의 장점

클래스를 논리적으로 그룹화
클래스가 여러 클래스와 관계를 맺지 않고 하나의 특정 클래스와만 관계를 맺는다면, 외부에 클래스를 새로 작성하는 것이 아닌 내부 클래스로 작성할 수 있다.또한 내부 클래스로 인해 새로운 클래스를 생성하지 않아도 되므로 패키지를 간소화할 수 있다.평소대로라면 아래처럼 외부 혹은 다른 파일로 클래스를 선언해놓고, 인스턴스화 하여 사용해왔을 것이다.

더욱 타이트한 캡슐화의 적용
내부 클래스에 private 제어자를 적용해줌으로써, 캡슐화를 통해 클래스를 내부로 숨길 수 있다.
즉, 캡슐화를 통해 외부에서의 접근을 차단하면서도, 내부 클래스에서 외부 클래스의 멤버들을 제약 없이 쉽게 접근할 수 있어 구조적인 프로그래밍이 가능해 진다. 그리고 클래스 구조를 숨김으로써 코드의 복잡성도 줄일 수 있다

내부 클래스 종류

인스턴스 클래스
스태틱 클래스
지역 클래스
익명 클래

다형성(Polymorphism)

J-Jay — Sun, 19 May 2024 16:48:14 +0900

다형성이란?

프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메소드 등)이 다양한 자료형(type)에 속하는 것이 허가되는 성질을 가리킨다. (by.위키피디아)

다형성 예시

UserRepository라는 사용자의 데이터에 대한 인터페이스가 있고,

이것의 DB를 초기에는 MySQL로 구현했다고 가정하자.

근데 배포하기 하루전 DB를 Oracle로 바꾸는 일이 생겼다고 할때

~~처음부터 다시 개발하지 뭐...~~

이런상황에서 사용할 수 있는게 다형성이다.

interface UserRepository {
	public createUser()
    public updateUser()
    public deleteUser()
    public getUser()
}

MySql

class UserRepositoryMySQL implements UserRepository {
	@Override
    createUser() { ... }
    
    ...
    
    @Override
    getUser() { ... }
}

Oracle

class UserRepositoryOracle implements UserRepository {
	@Override
    createUser() { ... }
    
    ...
    
    @Override
    getUser() { ... }
}

즉, 위와 같이 하나의 개념(UserRepository 를 DB로 저장)을 서로 다른 N개(MySql로 저장, Oracle 저장)의 개념으로

만드는 것을 을 다형성이라고 한다.

상속(Inheritance)

J-Jay — Sun, 19 May 2024 16:38:36 +0900

상속(Inheritance)

자바에서 상속이란 기존의 클래스를 재활용하여 새로운 클래스를 작성하는 자바의 문법 요소이다.

상속은 상위 클래스와 하위 클래스로 나누어 상위 클래스의 멤버(필드, 메서드, 이너 클래스)를 하위 클래스와 공유하는 것

부모와 자식으로 생각하면, 자식은 부모의 유전자를 물려받듯, 하위 클래스는 상위 클래스의 모든 멤버를 상속받게 된다.

하지만, 모든 멤버를 상속받더라도 항상 직접적으로 접근할 수 있는 것은 아니다.

상위 클래스의 필드나 메서드의 접근 제한자가 private이면, 같은 패키지일 지라도 하위 클래스는 해당 필드나 메서드에 직접적으로 접근하지 못한다.

상위 클래스의 필드나 메서드의 접근 제한자가 default이면, 상위 클래스와 하위 클래스가 다른 패키지일 때 하위 클래스는 해당 필드나 메서드에 직접적으로 접근하지 못한다.

이럴 경우, getter와 setter를 이용해 간접적으로 접근해야 한다.

자바에서의 상속은 상위 클래스는 여러 하위 클래스를 가질 수 있지만, 하위 클래스는 여러 상위 클래스를 가질 수 없다. 즉, 단일 상속만을 허용한다.

상속을 받기 위해서는 extends 키워드를 사용한다.

상속의 종류와 사용법

1. Single : A ← B 상속

class Parents {
}

class Child extends Parents {
}

2. Multilevel : A ← B ← C, … 형태의 상속

class Grandparents {
}

class Parents extends Grandparents {
}

class Child extends Parents {
}

3. Hierarchical : A ← B, A ← C, … 형태의 상속

class Parents {
}

class Child1 extends Parents {
}

class Child2 extends Parents {
}

만약, Child 클래스가 Parents 클래스로부터 상속을 받았다면, Child는 다른 상위 클래스에게 중복하여 상속받을 수는 없다.

class Person {
    String name;
    int age;

    void learn() {
        System.out.println("공부하기");
    }

    void walk() {
        System.out.println("걷기");
    }

    void eat() {
        System.out.println("식사하기");
    }
}

class Programmer extends Person {
    void coding() {
    	System.out.println("코딩하기");
    }
}

먼저, Person 클래스를 생성하여 사람의 공통적으로 가질 수 있는 속성과 행위를 정의한 후,

Programmer라는 직업을 가진 사람이 Person 클래스로부터 상속받아 coding 메서드를 추가로 정의했다.

이를 실행하면 다음과 같이 programmer라는 객체를 Programmer 클래스에서 생성하고, Person 클래스의 속성과 행위를 실행할 수 있다.

또한, 추가적으로 작성한 coding() 메서드를 통해 Person보다 확장된 기능을 실행할 수 있다.

public class PersonEx {
    public static void main(String[] args) {
        Person p = new Person();
        p.name = "홍길동";
        p.age = 20;

        System.out.println("이름: " + p.name);
        System.out.println("나이: " + p.age);
        p.eat();
        p.learn();
        p.walk();

        Programmer programmer = new Programmer();
        programmer.name = "머스크";
        programmer.age = 25;

        System.out.println("이름: " + programmer.name);
        System.out.println("나이: " + programmer.age);
        programmer.eat();
        programmer.learn();
        programmer.walk();
        programmer.coding();
    }
}

포함 관계 (Composite)

자바에서 포함(Composite)은 상속과 비슷하게 클래스를 재사용할 수 있는 방법이다. 클래스의 멤버로 다른 클래스 타입의 참조 변수를 선언하는 것이다. 즉, 클래스의 속성 값에 다른 클래스를 선언하여 사용하는 것이다.

// Address 클래스를 속성으로 가지고 사용하고 있다.
public class CompositeEx {
    int number;
    Address address;

    public CompositeEx(int number, Address address){
        this.number = number;
        this.address = address;
    }

    void printInfo() {
        System.out.println(number + ": " + address.city + ", " + address.country);
    }

    public static void main(String[] args) {
        Address address1 = new Address("서울", "대한민국");
        Address address2 = new Address("부산", "대한민국");

        CompositeEx result1 = new CompositeEx(1, address1);
        CompositeEx result2 = new CompositeEx(2, address2);

        result1.printInfo();
        result2.printInfo();
    }
}

    class Address {
        String city;
        String country;

    public Address(String city, String country) {
        this.city = city;
        this.country = country;
    }
}

IPC(Inter Process Commuication) - 4

J-Jay — Mon, 29 Apr 2024 22:54:30 +0900

IPC(Inter Process Commuication) Async(비동기) 패턴의 한계

→ 특정 상황들에서는 필연적으로 2번이상 데이터를 받을 가능성이 있다.

Async(비동기) 통신을 활용해서 중요한 비즈니스를 하기는 어려울까?

Q. Async에서는 2번이상 수신되는 것을 해결하고 싶으며, Sync에서의 장점으로 설명되었던 중요한 비즈니스에서도 리소스 활용을 최적화 해서 사용하고 싶다면 어떤 방법이 있을까?

A. 멱등성(Idemptotent)이 필요한 상황을 식별한다.

멱등성(Idemptotent) 이란?

→ 특정 호출이 1번 혹은 여러번 호출되더라도 서버의 상태는 1번 호출된 것과 동일해야 한다는 특성이다.
일반적으로 Update, Delete 요청은 멱등성을 가지며, Create 요청은 멱등석을 가지지 않는다.

Async(비동기) 통신에서의 멱등성

Async 통신은 기본적으로 멱등성이 보장되지 않는 통신 방식이다.

그럼에도 멱등성을 구현하기 위해서는 "무언가" 가 필요하다.

예를들어,

1. 멱등성 구현을 위한 DB Table(RDB)를 사용해서 멱등성을 구현
2. 여러 메시징 오픈소스

결론

IPC(Inter Process Commuication) 는 다수의 Process 이다.
일반적으로 Process는 서비스간의 통신이다.
IPC의 방식에는 크게 Sync(Http, gRPC), Async(Message Queuing)방식이 존재한다.
Async 통신에는 위와 같은 한계를 해결하기 위해 멱등성을 식별해야 하고,
최근의 메시징 시스템은 멱등성 기능을 내제하는 Exactly Once 기능을 제공한다.

IPC(Inter Process Commuication) - 3

J-Jay — Mon, 29 Apr 2024 22:34:40 +0900

IPC(Inter Process Commuication) Async(비동기) 패턴

→ Queue를 활용하여 Produce, Consume 방식으로 데이터 통신

MQTT (Message Queuing Templemetry Transport) - Spec ↓ 기능↓ 쓰지 않음
- 경량 메시징 프로톸로로서, IoT 경량화가 최대 목적인 프로토콜
- Publish, Subscribe, Topic 사용
AMQP (Advanced Message Queuing Protocol)
- 엔터프라이즈 레벨의 메시징 시스템을 위한 프로토콜
- MQTT 개념 외에도, Exchange, Binding 등 개념 추가
- Rabbit MQ, Active MQ...

Publisher(발행자)는 Exchange(Routing 역할)만 바라본다.

Exchange는 Queue를 통해 Consumer를 통해 Subscribe or Request to Message Sending 방식으로 사용할 수 있다.

Kafka
- 링크드인에서 개발한 대용량의 데이터 스트림을 처리하기 위한 분산 스트리밍 플랫폼
- MQTT, AMQP 등의 표준을 구현하는 프로토콜이 아닌, 독립적인 데이터 스트리핑 플랫폼
- 비교적 복잡한 개념들을 가지고 있지만, 성능(=메시지 처리량) ↑
- 고성능, 고용량 메시지 처리 설계
- JVM과의 좋은 궁합으로 폭넓게 사용
- 러닝커브 ↑

Kafka 아키텍처

Topic : Producer, Consumer의 메시징 객체 (~ 에 보내, ~로 부터 받아)
Partition : Topic을 물리적으로 분할 및 처리

Broker: Kafka 클러스터의 각 노드를 의미

Zookeeper : Kafka 클러스터의 메타데이터 관리

IPC(Inter Process Commuication) - 2

J-Jay — Fri, 26 Apr 2024 21:59:47 +0900

IPC(Inter Process Commuication) Sync(동기) 패턴

HTTP
OSI 7 응용 계층의 통신 프로토콜로서, L4 계층에서는 TCP 방식을 활용하는 프로토콜
여러가지 종류의 메서드가 존재하지만 일반적으로 4개의 메서드를 활용한다. (GET, POST, PUT, DELETE)
gRPC (google Remote Procedure Call)
Protocol Buffer 라는 것을 기반으로 하는 원격 프로시저 호출 프로엠워크
일반적으로 Server to Server Call 경우에 한해 사용
빠르지만, 번거로운 작업과 위험이 수반 (ex stub파일 생성, type을 하나만 잘못 넣어도 전체 error)

IPC(Inter Process Commuication)

J-Jay — Fri, 26 Apr 2024 21:43:47 +0900

IPC(Inter Process Commuication) 전 사전 지식

프로세스 간 통신 → 서비스 간 통신 → MSA

IPC를 이용하기 위해서는 Network 통신이 어떻게 이루어지는지 이해가 필요하다.

→ OSI 7 계층(Open Systems Interconnection), TCP/IP 모델

OSI 7계층(Open Systems Interconnection), TCP/IP 모델 들은 한 곳에서 다른 곳으로 통신이 어떻게 되는지
설명하는 모델이다.

논리적으로 이해 → TCP/IP (4 계층) 모델

ISO 표준 → OSI 7계층 모델

IPC(Inter Process Commuication) 방식

일반적인 IPC 는 크게 2가지로 나눌 수 있다.

Sync(동기) 방식 (Restful, Http, gRPC)
→ 적절
1. 굉장히 중요한 작업
2. 비교적 빠른 작업에 대한 요청
3. 선행작업이 필수적인 비즈니스

→ 부적절
1. 매우 복잡하고 리소스 소모가 많은 작업의 요청
2. 비교적 한정된 컴퓨팅 리소스를 가지고 있는 경우
Async(비동기) 방식 (rabbitmq, kafka, pusbsub)
→ 적절
1. 매우 복잡하고 리소스 소모가 많은 작업의 요청
2. 비교적 한정된 컴퓨팅 리소스를 가지고 있는 경우
3. 서버 리소스로 인해 누락이 생기면 안되는 경우
4. 독립적으로 실행되는 수 많은 서비스들이 있는 대용량 MSA환경

→ 부적절
1. 굉장히 중요한 작업
2. 비교적 빠른 작업에 대한 요청
3. 선행작업이 필수적인 비즈니스

MSA 분해로 인해 생긴 문제 해결 방법

J-Jay — Thu, 25 Apr 2024 23:10:10 +0900

"분해" 로 인해 생기는 문제 해결 방법

문제1: 수 많은 서버와 수 많은 서비스들은 어떻게 배포하고 관리 할 것인가?
해결1: Container로 관리 → Docekr
문제2: 그럼 많은 컨테이너는 또 어떻게 관리할 것인가?
해결2: Container Ochestration로 관리 → K8S, docker-compose(경량)
문제3: MSA환경에서의 모니터링(로깅, 메트릭, 트레이싱, 서비스 메시)은 어떻게 할 것인가?
해결3(로깅)
- 수많은 서버(IDC, CLoud 내의 수많은 서비스들의 로그들을 적절히 필터링 하여 누락없이 로그 저장소까지 전송
- 수 많은 로그들을 적절히 인덱싱 하여, 필요 시 빠르게 다양한 조건으로 검색
→ EFK, ELK

해결3(메트릭, 얼럿)
- 수 많은 서버(IDC, Cloud) 내의, 수많은 서비스의 메트릭들을 안정적으로 수집하고, 시계열 방식으로 저장 필요
- 다양한 오픈 소스의 메트릭을 지우너하는 대시보드를 사용
- 원하는 복잡한 비즈니스 메트릭을 작성하고, 이를 기반으로 적절하게 Alert 조건을 설정
→ InfluxDB, Prometheus(시계열 DB) / Grafana(visualize 예쁘게)

해결3(트레이싱)
- 하나의 소스(트랜잭션)에 대해서, 여러개의 서비스에서 어떤 과정들을 거쳐 수행되었는지 확인
- 적절한 샘플링과 보기 좋은 UI 제공이 필요
→ Jaeger(go 언어로 만듦), Zipkin, Tempo(Grafana에서 나옴)

Jaeger 트레이싱 아키텍처

해결3(서비스 메시)
- 어느 서비스가 어느 서비스를 호출하고 있는지, 어디로 트래픽이 어느 정도로 발생하고 있는지 모니터링 필요
- 수많은 서비스들이잘 호출되어 있는지 어떻게 하면 서비스들이 호출된것을 편하게 볼 수 있는지가 목적
→ kiali

MSA 분해로 생긴 문제들

J-Jay — Thu, 25 Apr 2024 22:23:23 +0900

1. 모듈간 통신 → 서비스(프로세스) 간 통신 (개발자 입장)

Method(Function) Call을 해서 → Network(http, grpc, ... ) 통신을 한다는 과정이라고 했을때,

일반적인 상황에서는 모놀리식이든, MSA든 전혀 차이가 없다.

하지만! 항상 모든 이슈는 문제(장애) 상황에서 발생한다.

발생 가능한 문제들

요청에 대한 처리량(throughput)이 급격히 하락↓
→ 필요한 컴퓨팅 자원의 최적화 어려움
→ 성능 하락 or 낭비 가능성
http,grpc 프로토콜 상의 이슈로 문제가 생기는 경우 디버깅이 어려움
→ Connection Pool 관리
→ 한정된 리소스로인한 JVM 최적화가 더 어려워짐으로써 의도치 않은 결과 발생 가능성 ↑
→ http, grpc 프로토콜에 디펜던시가 있는 지식 필요함 (Conn Timeout, tcp-3handshake 이해, grpc code, ...)

2. 모니터링 방식의 변경 (운영, 유지보수 담당자 입장)

모놀리식 환경

→ Node Exporter를 활용하여 Node(DB) 상태에 집중

MSA환경

→ Node 상태 뿐만이 아니라, 서비스 간 호출 상태 파악

→ Lantency 증감 확인, Call 증감 확인

→ 어떤 API 호출중인지 확인

→ Async 방식 등에 대해서도 모니터링 필요

- kafka 큐잉

→ 다양한 비즈니스 메트릭에 대해서도 어려워짐

발생 가능한 문제들

Network hop 이 늘어남에 따라, 어디서 어떤 요청에 대한 문제가 발생했는지 어려움
→ 서비스의 갯수가 늘어가면서, 어느 요청에서 문제가 발생했는지?
로그 수집을 위한 별도의 인프라 필요 및 관리 필요성 (DevOps)
→ 굉장히 복잡하고, 처리해야할 많은 문제들 발생(e.g 누락)
수십, 수백개의 서비스에 대해 JVM/하드웨어 얼마나 정상적인지 지속적인 확인 필요
→ 서비스 또는 서버에 문제가 생기더라도 적절하게 문제 감지 어려움
어느 서비스에서 어느 서비스로 호출이 되어야 하는지, 이게 정상인지 확인 필요
→ 서비스 간 호출 상태가 옳은 상태인지, 엉뚱한 서비스를 후출하지 않는지 파악 어려움