MyLogger만들어서 print하기

public class MyLogger {

private static boolean print = true;

public static void Log(String str) {
if(print) {
System.out.println(str);
}
}

public static void Log(String str, boolean flag) {
if(print) {
if(flag)
System.out.println(str);
}
}
}

댓글

댓글 쓰기

이 블로그의 인기 게시물

파일처리(한번에 모두읽기, 라인단위로 읽기, 쓰기, 리스트처리, 특정길이만큼 읽기)

이미지
텍스트 파일 한 번에 모두 읽기 (Utility 타입)   대용량 파일일 때는 메모리가 부족할 수 있으므로 ' 텍스트 파일 라인 단위로 읽어서 처리 ' 방식을 사용 public static String read(String filePath) throws IOException {        StringBuilder  stringBuilder;      FileReader     fileReader     = null ;      BufferedReader bufferedReader = null ;      try {          stringBuilder  = new StringBuilder();          fileReader     = new FileReader(filePath);          bufferedReader = new BufferedReader(fileReader);          String line;          while ((line = bufferedReader.readLine()) != null )            ...
자세한 내용 보기

AWS 가용성,확장성

이미지
1.  개요 On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.  그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다. 따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다. 또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다. 본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다. 2.  가용성 확보 방안 2.1.  센터 On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다. 해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.  클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같...
자세한 내용 보기

Serverless computing 도입시 고려사항

이미지
  1.  공급업체 종속성 서버리스 컴퓨팅같은 PaaS 서비스는 공급업체 종속성 Vender Lock-in  을 피할 수 없다. PaaS 서비스를 사용하다가 다른 클라우드 업체나 On-Premise로 이전하는 것은 막대한 비용이 발생한다. 또한 서버리스 컴퓨팅 은 제공하는 업체별로 사용 방법이 다르고 트리거 서비스가 각 공급사 서비스별로 연계되지 않기에 멀티 클라우드 전략이 어렵다. 한 예로 AWS Kinesis 라는 데이터 스트림 서비스는 AWS Lambda 와 연결하여 사용하나 Azure Functions 나 Apache OpenWisky에는 연계할 수 없다. 또한 특정 국가에서는 시스템의 서버가 반드시 해당 국가에 위치해야 하는데 CSP의 데이터 센터는 모든 국가에 위치해있지는 않다. 이런 상황에서는 시스템 수출 시 서버리스 컴퓨팅 뿐만 아니라 다른 PaaS 서비스들도 직접 구현해야 할 상황이 발생할 수 있다. 공급업체 종속성을 피하려면 오픈소스 서버리스 컴퓨팅 플랫폼을 이용 해야 한다.  2.  공급업체 마다 상이한 SLA 서버리스 컴퓨팅의 장점 중 하나는 서버 설정 등의 관리를 공급업체에서 진행하는 것이다.  하지만 공급업체의 실수로 장애가 발생할 수 있다.  한 예로 AWS의 Lambda 서비스 초기엔 잘 사용하던 함수가 몇 시간 동안 동작하지 않은 적이 있었고 AWS의 최초 서비스인 S3도 2017년 2월에 장애가 발생하여 이에 연결된 Lambda가 동작하지 않은 적도 있었다. [1]  이런 상황에 대비가 필요하고 필요에 따라서 보상을 받기 위해 SLA나 이용약관을 확인해야 한다.  AWS Lambda는 SLA가 없어 AWS의 문제로 인해 장애가 발생해도 보상 받을 수 없다.  또한 AWS의 Lambda 서비스 이용 약관에는 “AWS Lambda에 업로드된 고객의 컨텐츠가3개월 간 실행되지 않으면 30일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기