주인장은 현재 방송통신대학교에서 학업을 진행하고있다.

오늘 과제물을 하러 방송통신대학교 홈페이지에 들어가 과제물 공고를 받아서 진행하려하는데

소프트웨어공학이라는 전공 과제물을 진행하려다 한참동안 막혀서 글을쓴다.

현재 소프트웨어공학 과제물을 진행하고 있는데 문제점은!

과제물은 문제1번은 해당문제에 관하여 해당 과제물 공고에 명시되어있다.

그런데 2~4번 문제는 교재 연습문제를 찾아서 해야된다고 한다. 

가끔 이런 연습문제를 찾아서 하라는 과제물들이 가끔 나오는데 그럴경우 교수 홈페이지나 방명록에 개별적으로 연락하면 해당 문제에 관하여 보내주거나 다른곳에 명시를 해둔다. 심지어 방송통신대학교는 교재가 의무가 아닌걸로 알고있다.(이부분은 틀리면 댓글달아주세요)

그래서 교수 홈페이지에 들어가서 과제물 관련하여 문의하려했더니 누군가 해당 과제 관련해서 문의한 흔적이 보여서 들어가봤더니

교수가 답글단 글.jpg


?????? 내가 잘못봤나 싶어서 다시보니까 맞다. 심지어 교수 아이디로 적은게 맞다......

설마 이교수님 책팔아드실려고 하는건가 하고 확인해보니

교수.equals("책저자");


허허.... 그러셨군요 교수님....

이렇게 책팔아서 돈을 버시는거셨군요....


이해못하는것은 아니나 이렇게 고의적으로 과제물을 이용해서 반강제적으로 서적을 구매하게 한다는거 자체에 굉장히 실망하였고 두번째로는 내가 꼬여서 그런건지는 모르겠지만 위에서 보았던 댓글이 '나한테 직접적으로 물어보지마시고 과제하고싶으면 책사세요ㅎ' 로 밖에 안들린다.


그래서 책을 구매한 관계로 과제물 관련하여 궁금한점이 있으신 분들과 지식을 공유하려한다.


소프트웨어공학 과제물을 하기위한 연습문제에 관하여 궁금하신분들은 개별적으로 연락바랍니다.

ex)댓글, 방명록


그리고 얼마나 책을 잘썼나 꼭 다보고 리뷰달꺼다


'기타' 카테고리의 다른 글

[펌]대용량 세션을 위한 로드밸런서  (0) 2017.07.25
[스크랩] 2015 프로그래밍 언어 동향  (1) 2016.02.01
년초 작성된 DB정리  (0) 2015.11.27
뜬금 PHP 프로젝트 ...  (0) 2015.10.23
git 설치 방법  (0) 2015.10.23

요즘 솔루션SI회사에서 일하면서 공부를 병행하고있다. 아무래도 금융관련 프로젝트밖에 없으니까 신기술보다는 좀더 lowLevel의 기술이 많이 눈에 들어오는편이다(실무에 적용하거나 관련이 있는공부를 많이하기때문) 요새 주로공부하는게 서버(하드웨어포함) / 네트워크 위주로 공부하다 보면서 검색하던 와중에 로드벨런서의 세션처리 관련하여 좋은 글을 가져와본다.

출처 : 네이버 D2

-----------------------------------------------------------------------------------

대용량 서비스를 운영하려면 부하 분산은 필수입니다. 대용량 트래픽을 장애 없이 처리하려면 여러 대의 서버에 적절히 트래픽을 분배해야 합니다. 기존에는 세션 서버를 위한 로드밸런서로 DNS와 L4를 이용했으나 여러 가지 제약이 있어 네이버의 요구 사항을 충족하는 로드밸런서를 직접 개발하게 되었습니다.

이 글에서는 로드밸런서 개발 동기와 아키텍처를 살펴보겠습니다.

기존 로드밸런서의 제약 사항

DNS(Domain Name System)

DNS는 도메인 이름을 IP 주소로 변환하는 기술이다. 하나의 도메인 이름을 라운드로빈(Round Robin) 방식으로 여러 개의 IP 주소로 변환한다면 이것만으로도 쉽게 부하 분산이 가능하다.

그러나 여기에는 두 가지 단점이 있다.

첫째, 대부분의 클라이언트에서는 DNS 서버의 부하를 줄이고 성능을 향상하기 위해 일정 시간 동안 캐싱하기 때문에 부하 분산이 균등하게 되지 않는다.

둘째, 특정 서버에 장애가 발생하더라도 장애 여부가 감지되지 않아 서비스에서 해당 서버를 제거할 수 없다. 이것을 보완하기 위해 health check로 장애를 감지하여 DNS 서버에서 제거할 수 있지만, 모든 DNS 서버에 적용되는 데에 상당히 시간이 소요될 뿐만 아니라 클라이언트의 캐싱 때문에 서비스에서 바로 제거되지는 않는다.

L4

L4는 IP 주소와 포트를 기반으로 로드밸런싱하는 고가의 하드웨어로, 웬만한 서비스에서는 이것만으로도 부하 분산을 처리하기에 충분하다.

여기에서 주의해야 할 점은 L4는 VIP(virtual IP) 단위로만 로드밸런싱하기 때문에 반드시 하나의 VIP에 연결된 서버의 수가 비슷해야 한다는 것이다. 만일 서버 중 몇 대에 문제가 생긴다면 동일한 VIP에 연결된 다른 서버 역시 연달아 부하가 발생하여 더욱 심각한 문제가 발생할 수 있다.

또한 L4의 스펙상 최대 세션 수는 존재하나 세션을 맺는 시나리오에 따라 최대 성능이 다르기 때문에 최대 세션 용량에 도달하지 않았음에도 추가로 세션을 연결할 수 없는 문제가 발생하기도 한다.

마지막으로 통신사 장애 등으로 세션이 비정상적으로 종료된 경우 세션 서버에서는 클라이언트와 세션이 종료되고 정상적으로 다시 연결되었지만, L4에서는 세션 종료처리가 제대로 되지 않아 두 개의 세션을 동시에 유지하고 있어 L4의 한계 용량을 초과한 적도 있다.

개발 요구 사항

그동안의 경험을 통해 장애 대응에 필요한 기능과 운영 중 개선이 필요하다고 느꼈던 사항을 정리하면 다음과 같다.

클라이언트 접속 제한

세션 서버에 장애가 발생하면, 클라이언트는 로드밸런서에 접속할 때 새로 정의된 프로토콜을 이용한다. 새로 정의된 프로토콜은 세션 서버와 통신을 제한하여 장애 대응 시간을 줄일 수 있다.

세션 서버가 비정상적인 상황에서 클라이언트가 지속적으로 접속을 시도한다면 통신사의 네트워크 용량을 초과하여 심각한 문제를 일으킬 수 있다. 기존에는 응답 시간을 최소화하기 위해서 세션 서버와 세션을 항상 유지하려고 최대한 노력했으나 망 부하라는 부작용이 발생했다. 그래서 현재는 로드밸런서와 통신이 되지 않으면 클라이언트 자체적으로 재접속 타이머가 동작하여 망 부하를 최소화하고 있다.

L4 증설 시점 예측

최대 세션 수를 예측할 수 있으며, 앞으로 사용자가 늘어날 것에 대비하여 사전에 세션 서버를 증설할 수 있어야 한다. L4는 일반적으로 세션 유지가 필요하지 않은 웹 서버나 세션 수가 적은 서버의 트래픽 분산에 주로 사용한다. 앞에서 설명한 것처럼 L4의 스펙상 최대 세션 수는 존재하지만, 세션을 맺는 시나리오에 따라 최대 성능이 다르기 때문에 정확한 성능을 알려면 직접 테스트해야 한다. 그러나 수천만 세션을 직접 테스트하기란 현실적으로 불가능하다. 그래서 실제로 문제가 발생하고 나서야 L4 최대 용량이 얼마인지 정확히 파악할 수 있다. 이런 이유로 서비스의 최대 세션 수를 예측할 수 있고 장애 발생 시 아는 범위 내에서 대처할 수 있는 로드밸런서를 개발하고 싶었다.

서버 단위 로드밸런스

특정 서버에 부하가 몰리는 것을 막기 위해서는 VIP 단위가 아닌 세션 서버 단위의 로드밸런싱 기능이 필요하다. 그러나 운영을 하다 보면 VIP당 서버 수를 항상 동일하게 유지하는 것이 쉽지 않다. 그래서 서버 단위로 로드밸런싱을 하려고 한다.

다양한 로드밸런싱 알고리즘

상황에 따라 적절한 로드밸런싱 알고리즘을 사용한다. 가장 간단한 방법으로는 가용한 모든 서버에 라운드로빈으로 로드밸런싱하는 것이다. 이런 경우 서버 재시작 등으로 인하여 세션 수의 불균형이 발생하면 다시 고르게 분배되는 데 상당한 시간이 소요된다. 그러나 Weight Least Connection 등의 알고리즘을 사용하여 세션 수가 적은 서버에 가중치를 두어 트래픽을 분산한다면 세션 수의 불균형이 발생하더라도 금방 고르게 세션이 분산되므로 세션 서버의 배포 등의 작업을 쉽게 할 수 있다.

그렇다고 해서 무조건 그 서버에 트래픽을 몰아주면 해당 서버의 순간 TPS(transaction per second)가 높아 그대로 장애로 직결될 수 있음을 기억해야 한다.

세션 서버 배포 시간 단축

불필요한 세션 서버를 서비스에서 빠르게 제거할 수 있어야 한다. DNS에서 VIP를 삭제하여도 클라이언트에서 VIP 주소를 캐싱하고 있다면 몇 달이 지나도록 서버에 트래픽이 계속해서 유입될 수 있다. 따라서 서비스에서 제거하려고 DNS에서 세션 서버를 제거해도 세션 서버의 세션이 모두 끊어지기 전까지는 서비스에서 제거할 수 없다. 이런 DNS를 사용하지 않고 직접 개발한 로드밸런서를 통해 세션 서버의 주소를 요청한다면 이 문제는 해결할 수 있다.

전체적인 구조도

로드밸런서를 구성하는 모듈의 역할은 다음과 같다. 다양한 분산 알고리즘을 가진 조회 서버(lookup server)와 세션 서버를 관리하는 서버 매니저(server manager)로 나눌 수 있다. 그리고 세션 서버의 목록을 저장하기 위해 ZooKeeper를 사용했고, 세션 수 등을 비롯한 세션 서버 정보를 저장하기 위해 다양한 컬렉션을 제공하는 Redis를 사용했다. 그리고 단말과 1:1 세션을 맺고 있는 세션 서버가 있다.

각 모듈의 기능에 대해 좀 더 알아보면 다음과 같다.

loadbalancer1

그림 1 서버 구조도

클라이언트

클라이언트는 세션 서버 주소를 얻기 위해 조회 서버에 접속하여, 접속 가능한 세션 서버의 주소를 가져온다. 세션 서버의 주소를 정상적으로 수신하면 해당 세션 서버로 연결을 요청한다. 이 때 발생할 수 있는 상황은 크게 세 가지가 있다.

첫째, 모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 재접속을 시도한다.

둘째, 단말의 네트워크가 비정상이거나 통신사의 장애로 네트워크가 정상적으로 동작하지 않아 조회 서버와 통신하는 것조차 불가능하다면 클라이언트는 자체적으로 타이머를 두어 네트워크 부하를 최소화한다. 이런 경우 응답 시간 최소화보다는 네트워크 망 부하 최소화를 위해서 모든 클라이언트들의 타이머 값이 서로 다르도록 백오프 알고리즘을 통해 타이머 값을 설정한다.

백오프 알고리즘은 GCM(Google Cloud Messaging for Android)에서 사용되고 있는 알고리즘을 참고했다. 기준이 되는 백오프 타임이 있고 이는 최대 백오프 타임(MAX_BACKOFF_MS)을 초과하기 전까지는 두 배씩 증가한다. 실제 클라이언트에서 조회 서버에 접속하기 위해 재시도할 때마다 적용되는 백오프 타임은 기준이 되는 백오프 타임에 일정 수식을 사용하여 구한다.

Random sRandom = new Random();


int backoffTimeMs = getBackoff();  
int nextAttempt = backoffTimeMs / 2 + sRandom.nextInt(backoffTimeMs);


setAlarmManager(nextAttempt); // 실제 적용된 백오프 타임


if (backoffTimeMs < MAX_BACKOFF_MS) {  
    setBackoff(backoffTimeMs * 2); // 다음 백오프 타임을 구하기 위한 currentBackoffTime set
}

셋째, 정상적으로 세션 서버의 주소를 수신하여 세션 서버에 접속을 시도하더라도 접속이 원활하지 않을 수 있다. 이런 경우 일정 횟수 이상 재접속을 시도해도 세션 서버와 접속이 되지 않으면 해당 세션 서버에 장애가 발생했다고 판단한다.

이런 비정상적인 경우 처음부터 로직을 다시 수행해야 하므로 비용이 많이 든다. 이런 비용을 줄이기 위해서 조회 서버로부터 두 개의 세션 서버 주소를 받고 첫 번째 세션 서버에 접속되지 않는다면 두 번째 세션 서버 주소(Alternative IP)에 접속을 시도하여 비용을 최소화한다.

세션 서버

세션 서버에 추가된 기능은 주기적으로 세션 수를 서버 매니저에게 알려주는 기능과 서버 매니저의 L7 health check 요청에 응답하는 기능이다.

서버 매니저로부터 주기적으로 유입되는 health check 요청을 적절히 처리하여 세션 서버의 정상 동작 여부를 알려준다. 서버 매니저는 일정 시간 동안 health check에 실패하면 해당 세션 서버를 서버 목록에서 제거하기 때문에 자신의 상태를 정확히 전달해야 한다. 응답할 때 자신의 현재 세션 수를 서버 매니저에게 알려준다.

조회 서버

DNS 역할을 하는 Lookup 프로토콜 제공

클라이언트가 요청할 때 어떤 세션 서버에 접속해야 하는지 알려 주는 기능을 제공하며, 세션 서버의 배포 등으로 인하여 서버 목록이 변경된 경우 서버 매니저로부터 새로운 서버 목록을 수신하여 업데이트한다.

분배 알고리즘 변경

서버 매니저를 통해서 운영 중에 부하 분산 알고리즘을 변경할 수 있으며, 라운드로빈이나 세션 수를 고려한 Weight Least Connection 등 다양한 부하 분산 알고리즘을 사용할 수 있다. 현재 기본으로 사용하고 있는 Weight Least Connection 알고리즘은 세션 서버의 세션 수를 고려하여 세션 수가 적은 서버에 부하 분산 시 우선순위를 준다.

복수 지역(multi region) 지원

클라이언트가 보낸 MCC(mobile country code, 모바일 국가 코드)를 기반으로 지역을 선택하여 어떤 세션 서버에 접속해야 하는지 알려 준다. MCC와 지역 매핑 정보는 서버 매니저를 통해서 운영 중 동적으로 변경할 수 있다.

높은 TPS

서비스별로 수천만 명의 사용자가 Lookup 프로토콜을 요청하기 때문에 기존 L4만큼의 높은 처리량이 요구된다. Java 비동기-네트워크 프레임워크인 Netty를 이용하여 구현했으며, Lookup 인스턴스당 약 20,000TPS 이상의 트래픽을 처리할 수 있다.

암호화

클라이언트와 주고받는 모든 패킷은 암호화해서 보안을 강화했다.

서버 매니저

복수 서비스, 복수 지역 지원

한 세트의 서버 매니저는 여러 개의 서비스를, 그리고 각 서비스는 여러 지역을 지원한다. 예를 들면 LINE이라는 서비스와 그 아래의 Korea, China 등 다양한 지역을 지원한다. 지역별로 다른 세션 서버 그룹을 구성한 경우도 지원하고, 굳이 지역을 구분할 필요 없는 서비스는 Common으로 정의된 공통 세션 서버 그룹으로 처리한다.

만약 특정 지역의 모든 서버에 장애가 발생하면 다른 지역의 서버 그룹에서 해당 지역을 처리할 수 있도록 지역 페일오버(failover)도 가능하다.

서비스별 알고리즘 적용 가능

서비스별로 다른 분배 알고리즘을 적용할 수 있다. ZooKeeper는 서비스별로 분배 알고리즘을 관리한다. 알고리즘이 변경되면 조회 서버로 변경된 알고리즘을 전달한다.

세션 서버 정보 관리

서버 매니저(master)에서 주기적으로 세션 서버에 세션 수를 요청한다. 응답받은 세션 수를 Redis에 저장하고, 서버 매니저(slave)들은 Redis를 주기적으로 가져가 데이터를 동기화한다. 모든 서버 매니저는 세션 서버 정보를 가지고 있으며, 조회 서버가 서버 정보를 요청하면 자신의 데이터를 기반으로 서버 정보를 전달한다.

주기적인 health check

서버 매니저(master)는 운영 중인 모든 세션 서버에 주기적으로 health check 요청을 보낸다. 일정 횟수 이상 health check에 실패하면 ZooKeeper에 저장된 해당 서버의 상태를 suspended로 변경하고, 조회 서버에게 해당 서버를 서비스에서 제거하라고 알린다.

ZooKeeper에 저장하는 세션 서버의 상태는 다음과 같다.

loadbalancer2

그림 2 세션 서버 상태도

  • shutdown: 세션 서버의 인스턴스가 종료된 상태 또는 정상적으로 서비스할 수 없는 상태
  • starting: 세션 서버를 시작하고 있는 상태
  • standby: 세션 서버가 정상적인 상태이나 아직 서비스에 투입 전이라 클라이언트의 접속이 없는 상태
  • running: 세션 서버가 정상적이고 서비스에 투입하여 정상적으로 운영 중인 상태
  • suspending: 세션 서버가 오동작하여 서비스에서 제거하고 있는 상태
  • suspended: 세션 서버가 오동작하여 잠시 서비스에 투입하지 않은 상태
  • resuming: 세션 서버가 정상적이어서 다시 서비스에 투입하고 있는 상태
  • shuttingdown: 세션 서버가 종료하고 있는 상태

위의 여러 가지 상태 중 조회 서버에게 세션 서버가 서비스 중이라고 알려 주는 상태는 running 상태이고, 그 외의 상태는 모두 서비스에 아직 투입 전이라고 알려 준다. 현재 모든 상태가 구현되지는 않았다. 운영에 무리가 없는 상태까지 구현해서 오픈하고, 추후 확장 가능성을 열어 놓은 상태이다.

HA 구성

서버 매니저는 최소 두 대 이상(한 대의 master와 한 대 이상의 slave)으로 구성된다. master의 역할은 세션 서버의 health check와 ZooKeeper에 세션 서버의 상태 업데이트이다. 그리고 지역이나 세션 서버의 목록이 변경되면 조회 서버에게 알려 주는 역할을 한다.

slave의 역할은 ZooKeeper와 Redis의 데이터를 지속적으로 동기화하여, 조회 서버의 지속적인 요청에 응답하는 것이다.

장애 대응 시나리오

로드밸런서를 개발하게 된 가장 큰 동기는 장애에 유연하게 대응하는 로드밸런서의 필요성이었다. 통신사에 일시적으로 장애가 발생하여 수천만 사용자의 세션이 끊어지면 장애 시간 동안 단말이 지속적으로 재접속을 요청하여 트래픽이 평소 대비 100배 이상 급증하고 그로 인해 망 용량 초과가 발생한다. 그리고 장애에서 복구 완료 후에는 단말이 일시적으로 접속을 요청하여 서버 용량 초과가 발생한다. 이와 같은 장애가 발생했을 때 이를 처리할 수 있는 로드밸런서 개발이 목표였다.

구조를 설계할 때 일부 모듈의 장애가 전체 장애로 이어지지 않게 하기 위해 최대한 노력했고, 통신사 장애 및 IDC 등의 장애가 발생해도 망 부하를 최소화하고 더 쉽게 장애에 대응할 수 있게 설계했다. 각 모듈에 장애가 발생했을 때 어떻게 처리하는지 알아보자.

loadbalancer3

그림 3 장애 대응 시나리오

1. 세션 서버 장애 시

세션 서버의 장애는 주기적으로 health check를 하는 서버 매니저가 가장 먼저 감지한다. health check에 실패하면 서버 매니저는 변경된 세션 서버 목록을 조회 서버에 다시 전달한다. 조회 서버는 새로 받은 서버 목록으로 로드밸런싱한다.

클라이언트는 연결되어 있던 세션 서버와의 세션이 끊어지면 두 번째 세션 서버(alternative IP)에 접속을 요청한다. 두 번째 세션 서버도 접속되지 않으면 조회 서버에 새로운 세션 서버의 주소를 요청한다.

모든 세션 서버의 장애로 정상적으로 동작하는 세션 서버가 하나도 없다면 조회 서버는 세션 서버가 없다는 메시지와 함께 일정 시간 후 다시 접속하라고 응답한다. 이런 경우 백오프 타임 후에 조회 서버에 재접속을 시도한다.

2. 조회 서버 장애 시

조회 서버 중 일부에 장애가 발생해도 총 조회 서버의 서버 용량이 초과하지 않는 한 정상으로 동작한다.

조회 서버 전체에 장애가 발생하면 클라이언트는 백오프 타임 후에 재접속을 시도한다. 실제로 약 100만 개의 실제 세션으로 테스트를 진행해 보았는데, 조회 서버가 평소에 요청받는 만큼의 세션이 세션 서버에서 감소하고, 조회 서버 복구 직후에는 클라이언트가 백오프 주기에 따라 동작하며 일시적으로 요청량이 증가한다. 테스트 결과 10분 정도의 전체 장애가 발생했을 때 20분 이내에 모든 세션이 복구 완료된다.

3. 서버 매니저 장애 시

서버 매니저(master)에 장애가 발생하면 slave 중 하나가 master로 전환된다. 서버 매니저(master)가 ZooKeeper에 특정 znode를 ephemeral node로 생성하고, slave는 그 znode를 지속적으로 모니터링한다. 해당 znode가 사라지면 서버 매니저(master)가 비정상이라고 판단하여, slave 중 하나가 master로 전환하는 형태로 구현했다.

서버 매니저 전체에 장애가 발생하면 조회 서버는 실시간 세션 서버의 세션 수를 알 수가 없다. 이런 경우 조회 서버는 일시적으로 분배 알고리즘을 라운드로빈으로 동작한다. 서버 매니저 장애가 해결되면 다시 Weight Least Connection으로 동작한다.

마치며

지금까지 DNS와 L4라는 부하 분산 기술을 소개하고, 세션 서버를 위한 로드밸런서를 개발하게 된 배경, 전체적인 구성도, 그리고 모듈별 기능과 장애 시 대응 시나리오를 소개했다. 어느 정도 성능이 필요한 데이터 저장소는 지난 2년 동안 운영하며 장애를 일으키지 않은 Redis를, 서버 정보 관리 등의 분산 데이터 동기화가 필요한 부분에는 ZooKeeper를 사용하고, 단말의 높은 트래픽을 처리하기 위해서는 Netty를 사용했다. 추후 개발이나 아키텍처 구성 시 이러한 기술이 도움이 되길 바란다.

'기타' 카테고리의 다른 글

[분노] 방통대 소프트웨어공학 과제물  (17) 2018.04.09
[스크랩] 2015 프로그래밍 언어 동향  (1) 2016.02.01
년초 작성된 DB정리  (0) 2015.11.27
뜬금 PHP 프로젝트 ...  (0) 2015.10.23
git 설치 방법  (0) 2015.10.23

출처 :http://news.softpedia.com/news/java-was-2015-s-most-popular-programming-language-498648.shtml

==============================================

The TIOBE index is an established ranking system used to measure the popularity of programming languages. According to the TIOBE Company, the firm behind the index, 2015 was Java's year, which outmuscled C for the top spot.

Java was not only the overall winner for 2015, but compared to last year, it also recorded the biggest ranking change with a 5.94% growth.

Java, which was the dominant programming language at the start of the 2000s, has lost face to C in the past few three years. The recent resurgence can be easily attributed to the Android ecosystem, which helped drive Java's popularity up once again after Android-based smartphones started dominating the mobile market.

In a similar programming languages ranking system managed by PYPL, Java also ranked first at the end of 2015, but the PYPL index declared Python as the most popular language during the past year, with a growth of popularity of 1.1%, compared to Java's 0.4%.

On the other side of the spectrum, the TIOBE index declared Objective-C 2015's biggest loser with -5.88% while PYPL gave that title to PHP with -0.7%.

Also today, DB-Engine, another ranking service that focuses on database management systems, has declared Oracle the Database of the Year for 2015.

Here is the TIOBE index, as it stands in January 2016.

Jan 2016Jan 2015ChangeProgramming LanguageRatingsChange
12Java21.465%+5.94%
21C16.036%-0.67%
34C++6.914%+0.21%
45C#4.707%-0.34%
58Python3.854%+1.24%
66PHP2.706%-1.08%
716⇧⇧Visual Basic .NET2.582%+1.51%
87JavaScript2.565%-0.71%
914⇧⇧Assembly language2.095%+0.92%
1015⇧⇧Ruby2.047%+0.92%

For comparison, here's PYPL's January 2016 ranking. PYPL uses only data from Google Trends.

RankChangeLanguageShareTrend
1Java24.4 %+0.4 %
2Python11.8 %+1.1 %
3PHP10.7 %-0.7 %
4C#8.9 %+0.3 %
5C++7.6 %-0.6 %
6C7.6 %+0.0 %
7Javascript7.3 %+0.3 %
8Objective-C5.1 %-1.1 %
9⇧⇧⇧Swift2.9 %+0.4 %
10R2.9 %

+0.3 %


Java


 [REDMONK 2015 RANKINGS]



2015년은 자바의 해였던거 같다. 이 사이트 말고도 여러 사이트의 데이터들도 확인 해보고 StackOverFlow나 gitHub에서 태깅된 횟수도 자바스크립트와 비슷한 수준이며 꾸준히 상승하고 있다는점이 매우 고무적이다. 나 또한 꾸준히 자바 & 자바스크립트 위주로 공부 또는 작업을 하고 있는 입장으로써 매우 기분이 좋다. 

현재위에 보이는 그래프들과 구글에서 서치되는 언어의 양등을 고려해볼때 자바 - 자바스크립트는 현재 탑을달리고 있는상황이고 그밑으로 C, C++, C#등 C계열 언어들이 자리하고 있는것이 자주 보인다. 또한 PHP-Python-ruby의 3파전이 이번년도에는 어떻게 진행될지 상당히 궁금하긴하다. 또한 최근 몇년간 R의 지위가 상당히 올라온 느낌이다. 확실히 우리나라에서도 데이터마이닝이나 빅데이터등 최근 데이터취합이나 정렬등 비프래그로머들도 데이터에 대한 인식이 많이 바뀐건 사실이고 그러한 이유로 R의 상승세가 이어지는 느낌이 아닐까 싶다. 또한 Go언어, coffeeScript등의 언어또한 상당히 상위권에 자리잡고있다. Go는 꾸준한 성장세를 이어가고있어 이번에 작성자도 한번 공부해볼까 생각중이다. 확실히 구글에서 밀어주는거라 당분간은 배워서 나쁘지 않을듯.... Object-c는 꾸준히 하향의길을 접어들고 있고 그자리를 스위프트가 야금야금 갉아먹으면서 올라가고 있는건 기정사실이다. 아마 수년안에 오브젝트c는 쭉 내려올거같은 느낌이 든다. 그밑으로는 VB의 꾸준한 선방과 저 멀리잇는 델파이....그리고 생각보다 낮은 위치에 있는 Rust 등이 보인다.

별거 아닌 포스팅이지만 확실히 영원한 언어는 없는거 같다. 10~15년전만해도 C가 자바에게 자리를 내줄지 누가 상상했을까! 그래도 아직까지 자바는 C의 위상을 넘기에는 부족한 느낌인건 사실이다. 2015년 프로그래밍 언어 랭킹을 통해서 많은것을 알아간다.


'기타' 카테고리의 다른 글

[분노] 방통대 소프트웨어공학 과제물  (17) 2018.04.09
[펌]대용량 세션을 위한 로드밸런서  (0) 2017.07.25
년초 작성된 DB정리  (0) 2015.11.27
뜬금 PHP 프로젝트 ...  (0) 2015.10.23
git 설치 방법  (0) 2015.10.23

select 문  = 데이터 검색

 

select [ALL(*) / distinct] // 원하는 컬럼명(열이름),...  // distinct => 중복제거

from 테이블이름

[where 조건]

[group by {컬럼,,,,}]

[having 조건]

[order by {컬럼,,,,,}[asc(오름), desc(내림)]]

 

1. select * from employees; : employees 테이블에서 전체 컬럼을 보여달라 (테이블 전체내용보기)

2. select 필드명, 필드명, 필드명 from 테이블이름 ; 해당 필드명의 자료만 검색

  

 ** 필드명의 자료가  Number, 날짜 인 경우는 연산이 가능하다 

3. select employee_id, first_name, job_id, salary, salary*12 from employees;

 

 ** 필드명을 별칭으로 사용 수 있다. (단, 진짜변경되는 것은 아님)

 ** 별칭 사용법 ( 1. 필드명 as 별칭,  2. 필드명 별칭)

4. select employee_id, first_name, job_id, salary as 급여, salary*12 연봉 from employees;

 

5. select 필드명,,,,, from 테이블명 where 조건절

  => 조건은 대소문자 구별한다. 문자열과 날짜는 반드시 홑따옴표 한다.

  => 조건절의 구성(where 필드명 연산자 조건 )

 select employee_id, first_name, job_id, salary from employees where salary >= 10000 ;

 select employee_id, first_name, job_id, salary, job_id from employees where job_id = 'IT_PROG' ;

 

   and 조건 : (필드명 연산자 조건 and 필드명 연산자 조건)

               주어진 조건을 모두 만족하는 필드만 검색

              ~부터 ~ 까지의 범위를 포함하는 검색 (where 필드명 between 조건 and 조건)

 

select employee_id, first_name, job_id, salary from employees 

where job_id = 'IT_PROG' and salary >=5000 

select employee_id, first_name, job_id, salary from employees 

where employee_id >=150 and employee_id<=180 ;

select employee_id, first_name, job_id, salary from employees 

where employee_id >=100 and employee_id<=180 and job_id ='IT_PROG';

select employee_id, first_name, job_id, salary, hire_date from employees 

where hire_date >= '89/01/01' and hire_date <= '89/12/31';

select employee_id, first_name, job_id, salary, hire_date from employees 

where hire_date  between '89/01/01' and '89/12/31';

select employee_id, first_name, job_id, salary from employees 

where job_id = 'IT_PROG' or salary >=5000 

 

 or 조건 : (필드명 연산자 조건 or 필드명 연산자 조건)

             주어진 조건들 중 하나라도 만족하는 것이 있으면 모두 검색

   (in 연산자 : 같은 필드에서 or 연산자를 사용할 경우 사용) 

      => in  연산자 형식 : where 필드명 in(조건, 조건....)

select employee_id, first_name, job_id, salary from employees

where job_id = 'IT_PROG' or job_id = 'AD_VP' or job_id = 'FI_ACCOUNT' ;

select employee_id, first_name, job_id, salary from employees 

where job_id  in('IT_PROG','AD_VP','FI_ACCOUNT') ;

 

  ** distinct => 중복제거 

 select distinct 필드명 from 테이블이름 , => O (해당필드의 중복제거 됨)

 select distinct 필드명, 필드명 from 테이블이름 => X (중복제거 안됨), 

 select distinct job_id from employees;

 

  ** like 연산자 : 정확하지 않은 데이터를 찾을 때 

     % : 모든(*) , _ : 어떤 한 글자 ( 전체 글자수까지 맞춰어야 한다.) 

  select employee_id, first_name, job_id, salary from employees where first_name like 'J%'; (시작)

  select employee_id, first_name, job_id, salary,hire_date from employees where hire_date like '89%';

  select employee_id, first_name, job_id, salary from employees where first_name like '%i%'; (포함)

  select employee_id, first_name, job_id, salary from employees where first_name like 'J____';

 

  ** is null 과 in not null

   select *  from employees where COMMISSION_PCT = null => 데이터 못 찾음

   select *  from employees where COMMISSION_PCT is null => 데이터가 null인 경우 찾기

   select *  from employees where COMMISSION_PCT is not null => 데이터가 null인 아닌 경우

 

  정렬 : null => 오름차순일경우 맨 마지막, 내림차순일 경우 맨 처음

  select * from employees order by salary => 오름

  select * from employees order by salary asc => 오름

  select * from employees order by salary desc => 내림

 

////////////////////////////////////////////////////////////////////////////////////////////////////

 

dual : 오라클 가상 테이블

sysdate : 시스템의 오늘 날짜

 

숫자함수

 

ABS : 절대값  예) select 10 , -10 , abs(-10) from dual

 

FLOOR : 소수점 아래 버림

        예) select 34.6789, 34.4798, 34.5789,floor(34.6789), floor(34.4798), floor(34.5789) from dual 

 

ROUND : 반올림 (숫자) => 소숫점 첫째자리에서 반올림

        반올림 (숫자, 자릿수) : 

       select round(34.6489,1),round(34.6598,1) from dual // 소숫점 첫째자리까지구함 34.6 // 34.7

       select round(134.6489,-1),round(135.6498,-1) from dual // 130 // 140

 

TRUNC : 버림(숫자, 자릿수)

       select TRUNC(34.6489,1),TRUNC(34.6598,1) from dual // 소숫점 첫째자리까지구함 34.6 // 34.6

       select TRUNC(134.6489,-1),TRUNC(135.6498,-1) from dual // 130 // 130

 

MOD : 나머지 구하기

       SELECT MOD(27,2), MOD(27,5), MOD(27,7) FROM DUAL

       select * from employees where mod(employee_id,2) = 1 ; // 사원번호가 홀수인 사람구하기

 

////////////////////////////////////////////////////////////////////////////////////////////////////

 

날짜 함수

 

sysdate : 시스템 오늘 날짜 , 연산가능

select sysdate, sysdate+100 from dual

 

months_between : 두날짜 사이의 개월 수 구하기

select months_between(sysdate,'96/06/26')/12 from dual

select floor( months_between(sysdate,'96/06/26')/12) from dual

select trunc( months_between(sysdate,'96/06/26')/12) from dual

 

next_day : 해당 요일의 가장 가까운 날짜를 반환(지나간 요일을 찾지는 않음)

next_day(날짜, 요일) : 요일 => 일요일 = 1

select next_day(sysdate,'일요일'),next_day(sysdate,1),next_day('14/08/18',1) from dual

 

last_day : 해당 월의 마지막 날짜 반환

          select last_day(sysdate) from dual 

////////////////////////////////////////////////////////////////////////////////////////////////////

 형변환 함수

  

  NVL : null 값을 다른 값으로 변환 시킴

  NVL(널값, 변환시킬값) 

   select  COMMISSION_PCT, NVL(COMMISSION_PCT,0) from employees

최근 php로 사이트를 개발할 일이 생겨서 php를 갑자기 보는중이다. 기본적으로 소스분석이 어느정도 되서 php로 금방 개발하겠지라고 생각했지만 지금 급 후회하고 도서대여를 했다. 아무래도 템플릿이나 프레임워크같은 패턴을 이용한 개발작업 때문에 볼 소스가 많아지는것 같다. 현재는 기본적인 로직을 구현할 수 있게 되어서 샘플링 작업을 하는중이다. 이번기회에 php를 공부해야겠다.


http://msysgit.github.io/ 사이트에 접속합니다.

다운로드 버튼을 눌러서 다운로드 합니다.


계속계속~

Advanced context menu로 설치를 해줍니다

윈도우 cmd와 리눅스 명령어를 같이 사용할 수 있게 해줍니다 3번으로 설치합시다.

체크아웃 스타일, 커밋 스타일 설정입니다. 저는 window - unix 스타일인 1번으로 했습니다.

Windows8.1 64비트 기준으로 기본 path 입니다. Git Bash를 클릭합시다. 

실행이 되면 git --version으로 버전을 확인합시다!! 

확인이 된다면 설치 끝!

+ Recent posts