'허니몬의 IT 이야기'에 해당되는 글 397건

허니몬의 IT 이야기/리눅스 이야기, 우분투

우분투도 PC와 모바일 환경을 통합하는 것을 목표로 하고 있는데...

그런 열망이 묻어나는 운영체제일지도 모르겠군요.

아직 자잘한 오류들이 있기는 하지만, 쓰는데는 별 무리가 없어보입니다. ^^






사용하고 있던 12.04 LTS 64bit 에서 13.04 64bit로 변경 완료.




허니몬의 IT 이야기/리눅스 이야기, 우분투

출처  : http://www.liberiangeek.net/2012/03/disable-ubuntu-overlay-scrollbars-in-ubuntu-12-04-precise-pangolin/


우분투 유니티에 적용된 스크롤 기본 설정은 스크롤바를 감추고 스크롤이 발생할 때 화면 옆에 마우스를 대었을 떄 스크롤할 수 있는 버튼이 나타나도록 되어 있다.

그러나, 이런 방식으로 움직였을 때 스크롤의 움직임과 위치가 맞지 않는 문제가 발생한다. 그래서 오버레이 설정을 해제한다.

데스크탑 환경에서는 불필요한 기능이라는 생각이 든다.

gsettings set org.gnome.desktop.interface ubuntu-overlay-scrollbars false


적용전 :


적용후 :


허니몬의 IT 이야기/리눅스 이야기, 우분투

* 참고사이트 : https://launchpad.net/~git-core/+archive/ppa


ubuntu에서 apt-get을 이용하여 git을 설치할 경우 우분투 저장소에 설치된 배포본은 1.7.9.5 버전이 설치된다. 현재(2013.04.07. 기준) 배포되는 최신 안정판은 1.8.2 버전(http://git-scm.com/downloads)이다.

ubuntu apt-repository(PPA)에 git ppa를 추가하면 최신버전 설치가 가능하다.


* 설치방법

* sudo apt-get-repository ppa:git-core/ppa

* sudo apt-get update

* sudo apt-get upgrade

* git version

허니몬의 IT 이야기/IT 트랜드

구글리더 서비스가 종료된다는 이야기가 있은 후,

만약을 대비해서 OPML 파일을 보관하려는 용도로 다운받기 위해 구글리더에서 '가져오기/내보내기'를 선택했다.

'정보 내보내기'라는 항목이 언제 생겼는지는 모르겠는데, 일단 클릭해본다.

'Takeout 을 통해서 내 데이터를 다운로드해라.'라는 건데... 뭔소릴까?

가보니, 구글에서 사용한 서비스들과 관련된 서비스 항목들을 확인할 수 있다. ㅡ_-)> 흐음...

구글리더 OPML 파일을 다운로드 받으려고 '리더'를 선택한 후 [보관함 만들기]를 클릭한다. 이 화면에서 서비스를 선택하고 [보관함 만들기]를 선택하지 않고 [다운로드]만 눌러서는 아무런 파일도 찾을 수가 없다. [보관함 만들기]에서 보관함은 '내가 내려받을 파일을 압축파일 형태로 어느 공간(구글의 데이터 저장소 어딘가)에 저장하는 곳'이겠지. 이렇게 만들어진 파일은 구글에 어떤 용도로 사용이 될까나?

[다운로드]를 선택하면 앞서 [서비스 선택]에서 선택했던 서비스의 데이터가 저장되는 진행률이 나타나고 '완료' 상태가 되면 [다운로드]버튼을 눌러 파일을 다운로드 받을 수 있게 된다.

다운로드 받은 파일을 풀어보면 '서비스명'의 폴더가 존재한다. 나는 리더서비스를 선택/다운로드 했으니 '리더'폴더가 있다.

구글 리더를 사용하면서 작성했던 노트, 다른사람과 공유했던 내용, 중요표시(Starred)해둔 것들에 대한 기록을 json 파일로 함께 내려주었다. 흐음... 저런 데이터까지 내려줄 줄은 몰랐는데? 서비스를 개발할 때, 사용자들이 추후에 정보를 백업하려는 부분까지 잘 고려해서 구성해야겠다 싶어진다.

허니몬의 IT 이야기/IT 트랜드

* 일시 : 2013년 03월 16일

* 장소 : 강남 교보문고 23층 세미나실

* 날씨 : 나쁘지 않음

* 발표자료 다운로드는 [공감세미나 페이스북 페이지](https://www.facebook.com/groups/259972190680391/)에서

* 공감세미나 발표는 나중에 SKPlanet에서 녹화영상을 공개예정






## 오픈소스/무료툴을 활용한 부하/성능테스트 사례소개

### 발표순서

* 발표자 : 임성현(KSUG, 스펙트라) / 이경환(스펙트라)




* Content

1. 동기 - 부하/성능테스트

2. 성능/부하 툴 소개

3. 설치 가이드

4. 활용 가이드

5. 병목 발견 및 조치

6. 여러가지 함정들

7. 활용팁


### 내용

* 오픈소스로 되어 있는 성능측정도구들은 대부분 영어로 되어 있어 설치가 쉽지 않다. 설치가이드를 제공하여 쉽게 접근할 수 있도록 했다.

* 동기

* 오픈소스/무료 성능 툴이 필요한 이유

- 좀 더 빠른 시점에

- 개발자가 직접

- 부담없이

- 성능을 고려한 실험을 할 수 있도록

* 아래의 질문 해결

- Filter를 사용하면 **얼마나** 성능이 떨어질까요?

* 성능/부하 툴 소개

* 부하툴 : [nGrinder](http://www.nhnopensource.org/ngrinder)

- 소개자료 :  [prezi : 김광섭](http://prezi.com/sv1xtz75ybaq/ngrinder/)

* 자세한 설명

* nGrinder 구성

- nGrinder controller

- Agent

- script 중요

- **지성인이라면 회사 내 서버 혹은 로컬서버를 이용**

* 모니터링 툴 : AppDynamics 지원사양

* 성능툴 : New Relic : http://newrelic.com

* 장점 : 성능 모니터링 서버의

* OpenSource 툴 소개

* 설치 가이드 - overview

* 전자정부에서 공개한 게시판을 이용

- 다양한 비즈니스 로직을 가지고 있음

- WAS, DB

* nGrinder 3.1, 3.1.1 스크립트의 약간 차이가 있음

- nGrinder, nGrinder_agent 실행 설정이 다름

* AppDynamics 설치

* New Relic 설치

* 테스트 대상 환경 구성

- Tomcat, 전자정부 프레임워크 공개 게시판 설치

* Port정리 : 수정필요, 수정안함 구분

* catalina.bat 내에 apDynamics, newrelic 설정

* new Relic을 통한 성능 테스트

* 활용가이드

* nGrinder Basic

- 웹으로 화면 구성되어 있음

- script 작성 : Jython으로 작성되어 있음(새로운 언어에 대한 학습압력이 크다)

- nGrinder는 theGrinder를 감싼 웹 애플리케이션

- 브라우저 중에는 firefox가 제일 궁합이 잘 맞음

- proxy 설정해야함

- python coding:utf-8 설정

- ngrinder_agent/agent.conf

- 자신이 속해있는 agent를 등록

- 테스트 생성 및 실행

- 하나의 트랜잭션에서 얼마나 시간이 소요되는지

* Seesion 처리 - nGrinder 기본 제공

* JSON 처리 : 스크립트 만들 때 라이브러리/리소스 폴더 생성 후 JSON 라이브러리 업로드

- 스크립트 생성시 라이브러리 추가 가능

- 라이브러리를 Java로 작성한 후 jar로 만들어 추가가능

* 그 결과를 확인하기 위해서 appDynamics를 활용

* Sequence : 동일한 User ID를 막는다면 -> python의 글로벌 변수 활용

* Doc 생성 - groc 활용(http://blog.outsider.ne.kr/907)

- Python 문서화 도구

* 병목발견 및 조치

* 성능 측정과 함께 모니터링 해야할 것

- visualVM 의 snapShot 기능

- nGrinder

* 성능 측정 후에 모니터링 해야할 것

* WAS가 죽거나 멈췄을 때 확인해야할 것

- 메모리 덤프를 뜨고 툴로 확인

- 동시접속자가 증가하면 세션이 계속 생성됨

- 세션은 static 영역에서 정보가 기록됨

* **중요** : 성능 리소스를 확인해봐야할 것

- nGrinder의 TPS 만으로는 확인할 수 없다.

- DB 문제, 병목구간

- VisualVM을 활용해서 확인

- sampling 플러그인

* 활용팁

* [SUT, nGrinder, 전략]

* 오픈소스를 사용하며 얻은 경험을 피드백

* 발표 후

* 성능에 대해 무관심했지. 앞으로는 신경을 좀 써야겠어.

* 성능분석해서 어떤 의미를 둘 것인가를 고민


## 자바카페와 함께하는 Apache HttpComponents

### 발표순서

* 발표자 : 김흥래



### 내용

* 관련 사이트 : [http://hc.apache.org/](http://hc.apache.org/)

* HttpClient 의 new brand

* HttpComponent

* Web Spider, Http Proxy, Web Service System

* HttpClient, HttpCore 라이브러리로 구성

* Apapche Commons 프로젝트에서 독립 프로젝트로 승격

* ApacheCommons : [http://commons.apache.org/](http://commons.apache.org/)

* HttpClient의 시작 : Apache Slide 프로젝트 진행중에 HttpClient 모듈이 commons로 분리

* HttpClient Module : 사용되면서 인지도가 높아짐

* 2005년 : Jakarta Commons HttpClient

- Apache Commons 에서 가장 많이 사용되는 라이브러리 : Common Loggin

- HttpClient 3.x 출시

* HttpClient 3.x 와 HttpClient 4.x 호환성이 없음

- HttpClient 3.x Blocking I/O 만 지원, non-Blocking I/O 지원

- Java NIO 지원여부

* HttpComponents(HttpCore + HttpClient)

* [HttpCore](http://hc.apache.org/httpcomponents-core-ga/index.html)

* [HttpClient](http://hc.apache.org/httpcomponents-client-ga/index.html)

* [Http AsyncClient](http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) : HttpCore NIO 이용, 현재 베타버전 지원, non-Blocking I/O 기반

* Common HttpClient : 기존 HttpClient 3.x 지원

* HttpCore를 이용하여 구현함

* HttpCore 라이브러리

* Low Level HTTP 라이브러리

* Blocking I/O 기반 기술 제공

* non-Blockoing I/O 기반 기술 제공

* [HTTP 1.1 프로토콜](http://www.w3.org/Protocols/rfc2616/rfc2616.html) 완벽 지원

* HttpCore / HttpCore NIO

* HttpClient 라이브러리 특징

* 모든 HTTP 메소드 구현(OPTIONS, TRACE)

* Blocking I/O 기반의 동작방식

* HTTP 메시지 전송 및 수신 가능

* 손쉬운 HTTP proxy 구성 가능

* javascript 실행 불가능

* URI redirect 동작, HTML 랜더링 불가

* **Web Broswer** 가 아니다.

- 맞어. HTTP 통신만 지원하지.

- [관련페이지](http://hc.apache.org/httpcomponents-client-ga/primer.html)

* HttpClient

* ![HttpClient feature](http://hc.apache.org/httpcomponents-client-ga/images/browser.png)

* 모듈

- HttpClient

- org.apache.http 패키지 경로 획득

- DefaultHttpClient 생성

- HttpMime

- HttpClientCache

- CachingHttpClient 생성

* Http proxy

* Java URLConnection

- JDK 기본 API

- 성능적인 이슈가 존재함

* HttpClient 3.x

- HTTP 통신 라이브러리

- 쿠키 핸들링 가능

- Http Pipelining : 이미지 다운로드 시, 동시에 여러개의 연결시도

- 응답이 오기전 요청을 날린다?

* HttpClient 4.x

- 기존 3.x와 하위호환성 없음

- Non-Blocking I/O 지원(정확하게는 Http AsyncClient, 현재 베타)

- Proxy Cache 지원

* HttpComponents 사용예

* [pache Synapse](http://synapse.apache.org/)

- 서로 다른 서버들간의 통신을 프록시로 처리

- ESB(Enterprise Service Bus)

* Android

* 기타 

* 블락킹Blocking 에 빠진다는 것은 어떤 의미일까?

* Cross Domain 법칙?

* Proxy 처리의 이점에 대해서 공부해봅시다.

* Thread safe한 개발이라

* https, ssl 통신모듈 지원?

* HttpClient는 Browser가 아니다. 

* 안드로이드에서 유용하게 싸용했다. 


## OpenStack을 적용한 클라우드 컴퓨팅 환경의 구현

### 발표순서

* 발표자 : 안명호(MHR Inc, foolishjames.com)

* 참고자료

* [2011.11.25 / OpenStack한국커뮤니티 안재석 on DevOn](http://devon.daum.net/2011/pdf/b-1-openstack.pdf)


### 내용

* Project Mission : 450대의 서버를 가상화로 100대로 줄여 동일한 기능 수행!

* AWS을 만들고 기존에 있던 웹 호스팅일 하자.


* 희망찬 출발! :cloudstack(레퍼런스가 많아서)

- KT도 클라우드 컴퓨팅을 사용했었음

* 고객의 요구

- 안정정

- 성능저하 최소화

- **기존 시스템의 100% 이전**

- 다양한 서버 및 인프라 환경 지원

- 오픈소스 사용(VMware 로 실행시 5억원)

* 시험운영에서 많은 문제가 발생 : 설치 다음이 문제

1. 나만이 이 문제를 겪는 것은 아니다.

2. **질문은 많지만 답이 없는 경우가 대부분**이다.

3. 대부분의 답은 몇놈으로부터 나온다.

- 커미터가 대부분의 대답을 해준다. 

4. 소스코드가 깔끔하지 않다.

- function 이름이 비슷하고, 기능의 중복이 많다.

* 시험운영과 함께 포기

* 불안한 새출발 : OpenStack

* Python으로 진행

* 코드가 깨끗

* 질문과 답변 참여도가 높음

* 활발한 커뮤니티 활동

* Data swift : Data Storace 서비스

* 결정의 순간들Decisions

* CloudStack vs OpenStack

- **Hypervisor** : KVM or XEN

- 하이퍼바이저는 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼을 말한다. 가상화 머신 모니터라고도 부른다.

- KVM : Redhat 에서

- XEN : Cytrix 에서

- 하이퍼바이저가 서버를 만들어주기 때문에 클라우드 컴퓨팅에서 제일 중요한 요소이다.

- 어느 쪽을 선택하느냐에 따라서 성능을 판가름

- XEN < KVM 의 성능이 급격히 좋아지고 있다. 

- KVM이 설치, 유지관리가 쉬워짐

* 하이퍼바이저 : KVM 선택

- 버그수 : KVM 0 vs XEN 23

- 개발사 : redhat

- performance : KVM이 좋아졌어

* 스토리지 : 가상머신이 동작하는 디스크

- Local

- 성능은 뛰어나지만

- 유지보수가 어려워??

- Remote

- Hybrid

- 선택

- 가장 빈번하게 사용하는 리소스 : VM의 생성과 삭제

- AutoScale : 필요에 따라서 VM을 생성했다가 삭제하도록 하는 것

- OS 는 Local

- File이나 DB는 Remote(NFS) 처리

* Networking Model

- 네트워크 문제는 쉽지 않다.

- Physical Layer와 Logical Layer

- Flat

- 기존에 있는 Physical Layer을 그대로 사용

- **FlatDHCP**

- 네트워크 결정 판단 기준 : Multi tennants or Not?

- Single 여부?

- VLAN 

* 설치Installation

* Deployment tool

- 100대의 대상 머신에 대한 Deploy를 어떻게 할까?

- 3가지

- Del clover

- JuJu

- ???

- tool을 이용한 툴을 활용

* Devstack

- 동작한다Working!

- private Cloud : Rackspace

- 믿을만한 회사다!

- 조작Customization 가능

* Devstack 의 아쉬운 점

- 재부팅후 서비스가 재시작되지 않음

- Restart.sh script를 작성해서 등록

* Configuration

* 경험자의 조언 : 하지만 만나지 않는 것이 좋을 뻔 했다. "2개월 걸려 설치와 환경설정을 했고 실제 운영하다보니 예상치 못한 문제가 지속적으로 발생한다"고 했다.

- 노하우는 공개가 어렵지.

* **Logging!!**

- 본인 스스로 문제를 해결해야 하고, 해결하기 위해서는 정보가 필요하고 로그를 수집해야했다.

* 컴퓨터마다 log 수집

- rsyslog

- 3가지 레벨 

- Nova : 하이퍼바이저에 접근하지 않음

- Nova-compute.log

- libvirtd

- instance-xxxxx.log

- libvirtd.log

- HyperVisor

- XEN or KVM log

* Nova --debug

- 동작 프로세스 확인

* 착각!Migration

* 'Fedora 8'이 안되요!

- 지원여부를 확인

- VM 이미지를 이용해서 가상머신 생성

- Booting Error

- 문제의 원인은 Disk IO

- VM Image 생성 후 IDE IO를 수정해서 해결

* 배치Deployment

* Final Decision!!

- 4대 : 1.5개월

- 추가 96대 : Fabric

- 스크립트 Push실행

* VM Deployment Balancing

- 클라우드 컴퓨팅 : 4가지의 컴퓨팅 자원 제공

- DISK, CPU, Memory, Network

- Good machine

- Disk, CPU & Memory, Network

- Bad machine

- Network, Network, Network

- Disk, Disk, Disk

- 적절하게 컴퓨팅 리소스가 분배되어 처리되도록 처리

* 온전한 행복, 교훈

* **오픈스택 소스코드를 수시로 보게 된다.**

* **Virtualization Hardware Spec이 중요하다.**

* **Log와 Monitoring이 매우 중요하다.**

* Storage가 Performance Bottle Neck이 된다.

* **Automated Configuration Management가 필수**

* Balanced VM Deployment가 중요하다.

* Network performance Degradation을 예상

* 문제가 발생하면 직접 해결해야 한다.

* **Host Server 성능의 70%를 넘지 마라.**

* 결론은 Cloud Friendly Software Architecture!!

* OpenStack 팁

* Openstack에서 지원하지 않는 기능

- devstack 을 이용해서 upgrade 처리

* Openstack 을 이용한 구축

1. devstack(설치방법)

* Cloud Computing 이 가져오는 변화(개발자에게?)

1. 컴퓨팅 환경의 변화

- 물리적인 환경

- 아키텍처의 큰 변화

- Component jar -> API Service

- SQL DB -> NoSQL

- Tangled interface -> layered interface

- Fat complex Object -> Lightweight Object 

- Service

- Latency(데이터 동기화)

- Distributed(API Service)

2. DevOps = Developer + Operator

- DevOps - improvement -> Users -> Feedback -> DevOps

- 클라우드 환경에서는 자동화Automation이 가능하기 때문에 Operator의 역할이 자연스럽게 개발자에게로 스며들었다.

- Netflix

* 기타

* **개발환경이 크게 변화하고 있다.**


## 데이터를 실시간으로 모아서 처리하고자 하는 다양한 기법들

### 발표순서

* 발표자 : 김병곤(JBoss Community)




### 내용

* 빅데이터는 real-time으로 간다.

* KB 국민카드의 실시간 빅 데이터

* 금융권 최초로 실시간 빅 데이터 프로젝트를 추진

* 금융권에서는 RM에서 큰 쓴맛을 봤기 때문에 빅 데이터에 매우 조심하는 경향이 있음

* 과거의 방식과 별 차이가 없음

* 분석에서 접근하지 말고 기술적인 문제를 해결하는데 오히려 더 집중해야 함

* 상용 제품이냐 오픈소스냐는 중요하지 않지만 비용을 줄이기 위해서는 IT 전담조직의 의지가 필요

- 시작은 엔지니어에게서 시작된다.

* 실시간 빅데이터의 요건들

* 쇼핑몰 사이트의 사용자 클릭 스트림을 통해 실시간 개인화

* 위치 정보 기반 광고 서비스

* 시스템 정보 수집을 통한 장비 고장 예측

* 카드 결제시 각종 상황에 맞는 경품/쿠폰 제시

* Scale up vs Scale out

* Scale up : 하드웨어 스펙 증가(장비의 성능)

- Concurrent Programming

- 언어 :  Eralng, Scalar, Clojure

* Scale out : 서버의 갯수를 통한 수평적 확장

- Distriubted Programming

- 기법 : MapReduce

* scale up과 scale out이 교묘히 혼용되지만 기본은 Sacle out

* Scale up과 Scale out 선정기준

- Performance

* Scale out을 선택하는 가장 큰 이유

- 지리적인 분산 등의 여러요인을 고려해야 하기 때문에

* 하지만 Scale out은 어렵다.

- Availability, Scalability

* 실시간 처리 방식에 따른 기술적 특징

* 이벤트 중심 처리

- 시간에 따른 일련 연속된 이벤트 흐름을 처리

- 특정한 Time Window 또는 건수를 연속적으로 처리

- Scale up 아키텍처

- 선언적 Rule 기반 처리

- 단순한 시스템 구성

- 내가 긁을 때

* 스트리밍 중심 처리 

- 시간에 따른 일련의 연속된 이벤트 흐름 처리

- Scale out 아키텍처

- Computation 중심 처리

- 복잡한 시스템 구성

- 강남지역에서 해당카드를 긁는 사람이 몇명? 

* 실시간 처리를 위한 오픈소스

- Esper CEP, Drools Fusion CEP 는 손쉽게 가능

- Storm, Apache S4 프로그래밍으로 구현해야해서 어려움

* tweetping.net

* 데이터를 화면에 어떻게 뿌릴까(가시화)를 할 것인가?

- 고객이 데이터를 확인하려는 시점 등의 영향을 받음

- Log 수집 분석

- Bic data for Real-time it

- 더 많은 정보를 수집하고 팔아야 한다.

- 실시간!!!

* Splunk

- 비싸! 고가의 라이센스비용

* Sumo Logic

* 2013 아키텍처 컨퍼런스에서 발표했던 자료

- 필요에 따라서 적절한 자원을 선택 사용

* CEP & Flume & Hadoop

- Esper CEP

- Scale up 아키텍처 기반 이벤트 탐지

- Length Windows

- Time Window

- 최근 10분 이내, 20분이내


* 개발자의 Skill set이 달라진다.

- 시스템 엔지니어링이 동반

- 장비 설치 테스트

* MapReduce 처리방법

* 한 자바싱 10기가

* 단순무식한 방법이지만 빅데이터에서 사용하는 기본적인 방법

* 배치에서 실시간 처리

* Apache S4

* Yahoo

* Scale out 아키텍처 기반 분산 스트리밍

* Near Real-time search index

* Hadoop MapReduce

- Process Element(PE)

- 패키징을 해서 서버에 전달하면 알아서 분산처리

* Twitter Topic Counter

- DataPE -> Pojo 생성

* 동작하는 원리를 이해해야 하고

* 외부시스템과의 연계를 통해서 동작을 확인해야 하고

* 엔지니어링을 해야 한다. 

* Storm

* Twitter

* Scalable, Scalar로 구현

* 서버 -> TCP/IP -> Storm 전송 -> 수집데이터 MongoDB 등에 넣어 두었다가 데이터를 분석하여 Chart로 표현

* Bolt로 넣고...

* 손실율을 0%로 만들겠다. 

* Getting started with Storm

- 책을 따라서...

* 배운 것들

* 시스템 구축에 대한 노하우 또는 노력이 절대적으로 필요

* 상대방의 경험이 중요할 수도 있지만 중요하지 않을 수도 있다.

* 많은 하드웨어가 없다면 구현이 어렵다.

* 업무를 알아야 한다. 기술이 모두라면 좋겠지만 결국 업무를 알아야 한다.

* 모든 것을 실시간으로 할 수 없다.

* 실습 예제


* 내가 앉아서 듣고 싶은 내용은 뭘까나?? 나도 발표를 한다면 어떤 내용으로 발표를 할 것인가?

* **개발환경이 크게 변화하고 있다.**

* 누가 오픈소스를 잘 활용하느냐가 관건이다.

* 문서화, 커뮤니티, 성숙도 등을 고려해야 한다.

- 성숙도와 문서화가 중요하다.

* 인프라, 개발, 의 요소가 잘 잡혀 있어야 해. 

* 고객의 요구사항만 받고서 쉬이 접근할 수 없는 요건들이 있다.

* 실시간은 내가 시간을 유지하는 것이 아니라 시스템이 유지한다.

* 값만 넣어주면 된다.

* 시스템 구축과 차트를 그리는 것

* D3 프레임워크

* 조금 공부하고 효과를 볼 수 있는 분야

1 ··· 3 4 5 6 7 8 9 ··· 80
블로그 이미지

Email : ihoneymon@gmail.com 안녕하세요, 꿀괴물 입니다. ^^ 멋진 비행을 준비 하는 블로그 입니다. 만능형 인간이 되어 많은 이들에게 인정받고, 즐겁고 행복하게 살기를 간절히 원합니다!! 달콤살벌한 꿀괴물의 좌충우돌 파란만장한 여정을 지켜봐주세요!! ^^

허니몬