VIDEO
1. 시럽페이로 풀어본 보안 이야기, 임형태(매니저, SK PALNET)
1.1. 시럽페이 소개
간편결제 비용지불이 순수한 웹으로 구현된 시럽페이 1.2. 간편결제
핀테크와 다르다. - 핀테크: 은행권에서 사용하는 결제
Paypal과 같은 서비스 영역
2015년 금융결제원에서 규제를 철폐하겠다는 발표를 하면서 10개의 서비스가 출현 결제시장이 왜곡되고 불편했다. 보안 > 사용자 권리
'외부의 탈취와 훼손으로부터 보호 '하는 것!!
기존에 불편에 대한 생각을 다시 해보게 된다.
불편한 것이 정말 보안을 위해 적절한 것인가? 고민 & 과정
‘해결 방법보다 숙제 를 함께 풀고 싶습니다.’
해결한 것보다, 해결하는 과정을 이야기하면서 숙제를 던진다.
허니몬: 해결방법은 문제에 접근하는 사람과 관점에 따라 다양해질 수 있겠다.
1.3. 의사소통Communication
사람과 사람, 컴퓨터와 컴퓨터, 컴퓨터와 사람 의사소통 in 네트워크
Add WIFI ‘모든 것은 네트워크를 위해 존재한다’ 불특정 다수 의 네트워크1.3.1. 인증Authentication, 누구냐 넌?
식별을 하자. 가맹점 and 사용자
자원에 접근하고자 하는 모든 대상에 대해서는 인증 해야 한다. 1.3.2. 가맹점 인증
OAUTH2
Client credentials Grant 부여 ID/Secret token J avascript O bject S igning and E ncryption
무결성, 암호화를 위한 암호화 알고리즘, 알고리즘 데이터를 암호화해서 전달하고 이를 복화하여 사용하는거야? http://jwt.io 시럽페이의 가맹점 인증절차
사용자가 시럽페이 결제 선택 가맹점이 결제 데이터 구성 후 서명 시럽페이 서버로 전달 시럽페이 인증받고 결제데이터 + 서명 = 가맹점 인증 1.3.3. 사용자 인증
사용자 편의성 **Single Sign ON(SSO)**이 주는 이점
패스워드에 대한 피로감을 줄여준다. 토큰으로 인증을 대행한다. Single Sign on 발급조건: 두가지
자체 회원체계를 가진 신뢰된 가맹점 해당 가맹점에서 접근에 대해 사용자의 명시적인 동의 그외에는 ID/PASSWORD 방식 대응 1.3.4. 암호화 해시 함수
단방향 암호화
동일한 입력 = 동일한 출력
인덱스, 성능 암호화 취약성을 가져오게 된다. **Dictionary(Rainbow Table) Attack 빠른 처리 속도
암호화 해시 함수 취약점 보완
Salt
**Dictionary(Rainbow Table) Attack 저항 입력값에 대한 가변성을 줌 Key Stretching
Brute-Force Attack 저항 Strength를 부여 패스워드 암호화 in 시럽페이
HMAC PBKDF2: Password-Based Key Derivation Function2 Scrypt Invidual Salt(32bits) SHA256 성능적인 문제가 걸릴 수 있지만, ID/PASSWORD 체계에서는 괜찮다. 암호화에 대한 것은 개발팀에서 고려할 문제 1.4. 결제, 권한Authorization
인증 된 사용자가 얻은 권한
ID/PASSWORD 만으로는 결제에 대한 권한을 부여하기는 그렇다. ID/PASSWORD + PIN
결제 기능에 대한 접근권한을 얻기 위한 인증단계 권한(AS OAUTH2) in 시럽페이 권한을 위해서 인증이 필요하다.
적절한 인증을 거친 사용자에게 적절하지 못한 권한 을 주었기 때문에 문제가 발생할 수 있다.
보안: 인증Authentication 과 권한Authorization 의 적절한 정리가 필요함 인증의 요소
KNOW(인증번호, 핀) HAS(as SMS-OTP, ARS, OTP) IS(as 생체인식)
IN(Contextual, as FDS) 결제수락
명시적으로 사용자 가 결제를 하겠다는 의사를 취합
핀 번호 입력 == 카드를 긁고 사인을 하는 것과 유사함
추가인증
편리함 in 안전함
결국은 인증과 권한의 균형 <- 제일 중요한 키워드군요. 1.5. 우리 둘만 아는 이야기, 의사소통(통신)
1.6. 마치며
보안은 어렵습니다. ㅠㅠㅠ
사슬의 약한 부분만큼 강하다.
굳이~ ActiveX, 보안모듈을 설치하지 않더라도 사용자에게 보안솔루션을 제공할 수 있는 서비스를 만들자. 1.7. 정리
시럽페이 보안: 인증 과 권한 을 조화롭게 다루어 의사소통을 하도록 하여 결제를 편리하게 할 수 있도록 유도하는 것이 목표!!
비싼 점심. 맛있음. +_+)b
2. Fast and Beautiful: Serving High Quality Pohotos at Scale on Flickr, Hugo Haas
2.1. 플리커 고해상도 사진의 공유
2… 플리커의 사용자 경험 공유
플리커, 훌륭한 컨텐츠: 멋진 사진들
컨텐츠만으로즌 부족하다. 이것을 공유하기 위한 것이 필요하다. 빠른 속도(쉽고! 짧고 분명한 가치) 문제 높은 기술수준 2.3. 아름다움, WHhat does beautiful mean?
주관적이지: 고양이 사진 Feature 사용자가 사진을 맘에 들어할 지 그렇지 않을 지에 대한 기술적 접근 2.4. 빠름, What does fast mean?
API 응답성 사진 제공 스크린 스크롤 읽어오기 화면비율 여러가지 레벨로 적용가능 Server side -> User interaction 2.5. Challenge:
2.5.1. Designs are more immersive
2.5.2. 해상도Resolution
해상도, 사용자에게 제공하려고 하는 컨텐츠가 점점 거대해지고 있다. 네트워크의 대역폭은 지역별로 차이가 크고 그렇게 높지 않다.
2.6. 해결책
2.6.1. First things, Instrumentation!
2.6.2. Analyze, Analyze, Analyze
커넥션의 연결상태 지리적인 부분
다운로드 속도, 렌더링 속도 첫바이트, 라스트 바이트 2.6.3. 서버사이드 그리고 Latency
서버사이드에서의 최적화 ! 테스트 코드
작성된 코드의 작성시기 작성된 코드의 변경사항에 따라 속도의 영향을 끼친 것 하드웨어의 변화 하드웨어 속도를 향상시키기 위해서 고려해야할 점들이 많다. 속도에 대해 최대한 빠르게 파악하여 속도저하를 해결하려고 해야 한다. 속도저하가 발생하는 것은 게으른 것 이다. 클라이언트 - 서버, 160ms 차이
HTTP 통신
SSL Handshake HTTP Request Server-side Response Data transmission 최적화를 위한 포인트를 찾다.
브라질에 있는 경우 15-40% 의 개선이 있었지만 실제로 느끼게 되는 것은 5-10% 향상효과밖에 없다. 유저들에게 돌아가는 혜택이 줄어들 수밖에 없게 된다. 2.6.4. Where do we spend time when getting media?
connection && request + server processing + response transfer(Largest payload!!)
전송 바이트를 줄일 수 있을까? Can we send less byte? Encoding & compressing… with care
사진을 더 압축!!
compressing!! noise 600kb, 85kb 를 두고서 고객에게 이야기 했을 때 같다고 이야기할 것인가? 노이즈를 줄이면서 압축효율을 높이고 싶다. 2.6.5. 노력을 통해 얻은 진전
비슷한 화질을 50%의 사이즈로 전송할 수 있다. -> 비용이 높다.
원본사진을 가지고서 특정한 사이즈별로 만들어서 제공하게 되었다.
오랜시간을 들여서 이미지의 크기를 줄이고 빠르게 전달할 수 있는 방법을 찾기 위해 노력했다. 2.6.6. 빈도?Latency
360kb -> 3.7s, 120kb -> 2.9s
작게 만들었지만 그보다 더 제한을 주는 요소가 있다. 대역폭별 속도를 분석했다.
특정시점에 이르러 비슷한 상황이 된다. 클라이언트와 서버의 거리, 연결connection 대역폭 vs 서버와의 거리
2.7. 문제점
2.7.1. Lowering the latency: bring content closer to the user
페북과는 다른 플리커의 사용자와 친구 관계
페북과는 다르게 플리커는 컨텐츠(풍경, 이미지)에 따라서 관심을 가진 대상들이 거리가 다양하게 된다. 관심사의 거리 15B 이미지를 다루는 것은 어렵다. 이미지 카피를 사용자에 가까이 유지
user - Regional cache - Image store 사용자가 만들어낸 컨텐츠를 제공하기 위한 다른 캐시를 도입 2.7.2. Regional cache & CDN to the rescure
호주의 reginoal cache 로드타입 전후에 따른 속도차이
컨텐츠를 유저 가까이 가져오면 큰 차이를 보이게 된다. 2.7.3. 시도
서버의 속도를 향상 이미지 사이즈 조절 서버의 거리를 줄이기(Regional cache)를 통해서 사용자 가까이에 컨텐츠를 두었지.
서비스를 개선하기 위해 노력해왔지만, 이를 더 개선하기 위해서 더 할 수 있는 것들이 있을까?
클라이언트가 속도를 향상시킬 수 있는 좋은 장소다.
Client is the best place to make things faster 다음 장소, 이전 결과를 제공하여 사용자의 행동 을 유도 클라이언트가 사용자에 관한 컨텍스트를 가지고서 예측하여 먼저 제공한다. 클라이언트 를 스마트하게 만든다.
Make the client smart Use local cache 기회예측, 사용자 행동예측 But not too aggressively
대역폭에 따른 사용공간의 변화 Prioritize request 50~70% 예측
이것은 치팅(눈속임?) 그렇다고 분노할 필요는 없지.
많은 시도!!!
2.8. 요약
균형을 잡는 흥미로운 행위
measure
Experiment
Look at all layers of the stack
사용자client 측에서 시도할 수 있는 것들이 있을까??
단축할 수 있는 것들이 많다. 시도해볼 수 있는 것: 다각 사이즈 조절 실제속도보다 빠르게 보이게 만들 수 있는 것
캐시
앱에서 어떤 것들을 제공할지를 결정하는 것이 중요하다.
jpeg, 포멧별로 접근, 요구사항이 다르다.
2.9. 정리
사용자에게 '쾌속’과 '아름다움’을 제공하기 위한 노력을 멈추지 마라. 속도를 저하시킬 수 있는 부분들을 찾고 찾아서 그것을
최적화를 시도하라. 그리고 최적화를 할 수 있는 적절한 공간은 사용자측 client 가 될 것이다. Cheatting!!
3. Sclable Network for the Next Generation Resource Scheduling: 공용준(아키텍트, 카카오: Andrew)
아키텍트로 가는 길
다음세대 자원관리를 위한 유연한 네트워크설계? 3.1. Term
3.1.1. Scale
3.1.2. Network
3.1.3. Scale Network
네트워크를 아무리 키워봐야 소프트웨어가 그대로면 별다른 변화는 없다?
빵빵한 네트워크가 있다고 해도 그걸 활용할 수 없다면 슬프겠지…? 2 by 4, 4명이서 2달해보고 잘되면 쉬자? 개발자, Step(비개발자)들도 가상서버를 자유롭게 만들 수 있다. 45000 krane, VM 서비스만으로 상당하나 규모를 사용하고 있다. 오픈스택에 3000 VM을 가지고 있다.
상당히 많은 것들이 구동되고 있으며, 이를 AWS에 올렸으면 상당한 비용을 지불했어야 할 것이다. 2, 3명이서 관리하고 있다. 대부분의 시스템이 자동화 되어 있기 때문에 적은 인원으로도 관리할 수 있게 되었다. 3.1.4. Scale growth -> 자원이 고갈되고 있다.
3.1.5. 개발자들의 욕심에 따라서 언젠간 자원은 고갈되게 된다.
CPU, Memory, Sotrage always experience shortage. They hav skewness IP is also Resource
IP 부족으로 서버를 생성할 수 없는 경우가 있었다. IP는 까다로운 자원이다. 서브넷을 나다는것은 게이트웨이가 분할되어 있고 게이트웨이는 지역성을 가지고 있다. SDN without SDN : Openstack
10.0.0.1/32 or IP 10.0.0.1 netmask 255.255.255.255 유투브 조회수, Openstack foundation SDN, Overlay 네트워크 VPN이 있는 회사가 좋은 회사?
라우팅 테이블 private 네트워크를 겹치지 않도록 하는 경우가 많다. 암호화
암호화를 하기 위해서 CPU를 사용하면서 속도가 느려질 수 있어? Calico, Cumulus linux L2 네트워크 인스턴스의 단점
라우터는 유연한 네트워크를 처리하기 위해 잘 갖춰져 있다. 3.2. Next Generation Resource
3.2.1. Container
모든 리소스를 표준화 less mutable things
pips, gems, war, packages 컨테이너만으로는 의미가 없다. 컨테이너: 사이즈가 정해져 있다.
IT 리소스가 표준화 되어 있다면 어떨까?! 클라우드 서비스간에 인스턴스가 표준화 되어 있지 않다. 서비스 제공자는 표준만 제공 개발자가 아닌 곳에서 제공
3.3. Nework Next generation Network Resource Scheduling
프록시 의존적인 네트워크는 안정적이지 않다. 네트워크
HTTP, CURL 을 통해서 접근하고 싶다. Overlay 퍼포먼스가 좋지 않다.
OPEN FLOW???, OVS??? multicast debugging…? 3.4. 컨테이너가 가지고 있는 네트워크의 속성을 변경해보자.
컨테이너 내부 IP를 라우팅되는 IP로 변경해보자.
blog.midonet.org , using docker libnet
Container 를 위한 Dynamic 주소 처리가 가능해? 조만간 이런 한계들이 개발될 가능성이 있다. in this planet, we’re not alone.
3.4. 어려운 일 vs 시간이 오래 걸리는 일
3.5. 정리
제일 중요한 것은 한번 해보는 일 이다.
KField network
컨테이너, IT 리소스 표준화, 네트워크 성능개선…
4. How to make your team successful with github(or Breaking silos), TAKAFUMI IKEDA(Sales engineer, Github) ikeike443
깃헙을 이용해서 성공적인 팀 만들기 저자
http://www.yes24.com/24/Goods/14725219?Acode=101
4.1. 성공으로 이끄는 팀 개발 실천기술 저술
4.2. github universal 소개
지금까지 소프트웨어를 사용하지 않았던 사람들이 자신의 문제를 해결하기 위해서 소프트웨어를 사용할 것이다.
NASA에서도 깃헙을 사용하고 있다. PIXAR
뛰어난 애니메이터와 엔지니어는 비슷한 점이 많다. 이터레이션을 반복적으로 한다. 팀웍이 중요하다. 모든 팀원들이 훌륭한 애니메이터다. GE
이전까지 소프트웨어와 관련이 없다고 생각한 이들도 깃헙을 사용하고 있다. 정부 기관의 정보를 깃헙에서 공개하고 여러사람들이 함께 만들어가고 있다. 깃헙은 카페인을 좋아하는데, 알콜도 좋아한다. Octoshop 4.3. Git LFS 1.0
Large File Storage 1.0 Integration Directory YubiKey
4.4. Agenda
4.5. Why do you need github
4.5.1. Every company is a software company
테크놀러지가 모두 소프트웨어와 서비스로 이동하고 있다. 우버
에어비앤비 라인
소프트웨어와 관계가 없다고 생각했던 기업들이 이동해가고 있다. 4.5.2. What’s happening in Dev world todays?
Needs
High velocity good user experience & High Quality Quck & innovation Pain points
very slow & unreliable dev/deploy flow no code review, no ci, too many regressions No transparency, Reinvent the wheel, silos 4.6. Where software is built?
4.6.1. Github flow
4.6.2. Branching is quick and easy
Experimentation without risk Branches should be shot lived Github이 아니라 GIT 이 가진 강점이지. 4.6.3. Collaborate with anyone on the Pull Request
모든 사람들이 협업을 할 수 있게 되었다!? Involve anyone to make it 4.6.4. Test it before merging
머지하기 전에 테스트를 해서 검증하는 것이 중요하다. 4.6.5. Merge it! with any condition you prefer
Protected branches and required status
4.6.6. Revert pull request
풀리퀘스트 단위의 revert 기능을 제공 Pull request didn’t go as planned? revert! 4.6.7. Web Blame and Linked pull request information
4.6.8. Closing issue pull request
4.6.9. Global Issue and Pull Request
4.6.10. You can find everything here
Great talent, useful code are already here 많은 것들을 찾아볼 수 있어. 4.6.11. Emoji
4.7. Wrap up, Breaking up your silos
모든 정보가 한군데에 모인다. 누구나 접근할 수 있다. 변경하거나 협력하는 일에 대해서 겁내지 않아도 된다. 사일로에 갇힐 필요가 없다. 4.8. 정리
5. 흔히 발견되는 자바 웹 애플리케이션 아키텍처 안티패턴(박성철, 본부장/SK PLANET)
아키텍처 -> 애플리케이션 아키텍처 -> 구조적인 접근 안티패턴
학습을 하다보면 정상치
새로운 시도
새로운 지식, 학습 내가 가지고 있던 역량보다 낮아질 수 있게 된다. 모험 프로그래머들 스스로 하고 있는 일이 무엇인지 어떤 것인지 알지 못한다.
87년생설 C/S 패턴
5.1. 연통가설
애플리케이션의 각 모듈이 독립적으로 개발되어 다른 모듈과 로직이나 데이터를 공유하지도 않고 상호작용하지도 않는다.
중복이 발생할 수 있다. 관심사에 따른 계층 설계
관심사 분리 원칙에 따라 계층도 각 계츠으이 관심사에 따라 설계 5.2. 뒤범벅 아키텍처jumble architecture
무거운 서비스
5.2.2. 해결책
애플리케이션 서비스 계층 추가 파이프 & 필터 패턴
AOP
기능에 직교적인 횡적 관심사를 분리해 모듈화 수준을 높이는 기술 5.3. 긴 공개 메서드long method
클래스에 공개 메서드 뿐이고 각 메서드의 크기도 너무 길다.
미미한 기능 분화, 낮은 유지 보수성 중복 다량 발생 단일 책임 원칙 위반 기능 분화로 재사용 코드 발견, 추상화의 기회 클래스 추가 공포증 5.3.2. 해결법
5.4. 하는 놈 따로, 아는 놈 따로
5.4.1. 도메인 모델 도입
5.5. 낮은 응집도 높은 결합
5.6. 오염된 도메인
도메인 영역의 모델만 가지고 도메인해야 한다. 5.7. 정리
시도하고 실패하고 경험을 쌓자.
6. Docket 클라우드 환경 구축 프로젝트 - d4, (황상철/SK PLANET)
… 못들음…
* 황상철님 발표자료: http://readme.skplanet.com/?p=11449
0. 정리
Tech planet의 강연은 만족스러웠다.
DEVIEW 2015 와 TECH PLANET 2015에 참가한 깃헙의 발표는 이제 듣지 않아도 될 것 같다.
깃을 기반으로 한 개발을 자연스럽게 하게 되면서, 굳이 깃헙 서비스를 중심으로 개발을 하지 않아도 충분히 개발과 관련된
버전관리를 할 수 있는 대안들이 많이 있는 상황이기 떄문이다. 어제 스쳐간 글들 중 드랍박스에서 구글 드라이브로 이주해가는 것에
대한 글들도 많이 나왔는데 개발 버전관리시스템도 그와 같다고 할까?http://www.yes24.com/24/Goods/14725219?Acode=101 )’ 이 책의 저자가 왔었지만… 그다지 흥미롭지는 않았다. Git LFS(https://git-lfs.github.com/ )에 대한 이야기를 해줬으면 흥미를 주었을지도 모르는데…
