애플 페이 SRE 인터뷰 후기

Apple Pay

애플 페이 지원계기

애플 페이 SRE로 지원해서 결과가 나오기 까지 두달간의 결과를 정리한다. 애플이 조직별로 (애플 맵, 애플 페이 등등) 채용과정이나 HR정책등이 많이 다르다고 알려졌지만,, 참고용으로 정리해둔다.

링크드인에서 애플페이 채용공고를 보고 자세히 알아보게 되었다. 동경에서 일할 SRE를 찾고 있었는데 JD에는 스마트 카드 관련 우대사항은 적혀 있지 않았다. 아마 관련 경력을 가진 사람이 적어서 쓰지 않았던 것 같다.

전 회사에서 SRE조직과 일을 한적이 있었는데, 전체 시스템을 버드아이 뷰로 보는 장점이 있어서 관심을 가지고 있었다. 거기에 애플페이라니, 스마트 카드업계에 있을때는 선망의 대상이었기 때문에 망설임 없이 지원하게 되었다.  그럼에도 SRE관련 경력이 전혀 없었기 때문에 큰 기대는 하고 있지 않았는데 3일뒤에 코디네이터로 부터 연락이 와서 롯폰기로 와달라고 했다. 다른 소프트웨어 회사와는 다르게 애플은 일정도 물어보지 않고 날짜를 미리 지정해서 통보했다. 이때부터 다른 소프트웨어 회사와는 분위기가 많이 다를 수 있겠다고 생각을 했다.  보통 소프트웨어 엔지니어 면접 시에는 어떤 질문을 할건지 지침등을 알려주는데 예상 질문도 전혀 없이 “I would recommend you to read up about ApplePay technology.” 라는 답장만 왔다.

애플 페이 1차 면접

1차 면접은 롯폰기에 있는 모리타워에서 인터뷰어 2명과 총 3시간 동안 면접을 진행했다. 첫번째 면접관은 라쿠텐 출신의 주니어 경력을 가진 다른 SRE였다.

  • 앤서블 사용여부
  • 이전회사 릴리즈 프로세스
  • 스플렁크 써본 경험? 로그 어떻게 조회하나?
  • SSL에서 대해서 설명해봐
  • Two way SSL에 대해서 설명해봐 (디테일한 그림 그림)
  • TCP/UDP 차이점
  • 로드 밸런싱
  • 자바카드에 대해서 설명
  • 기타 등등..

일하게 될 팀의 가장 막내 SRE인것 같 같은데 사실 지식이 그렇게 깊어 보이진 않았다. 아마 인원이 소수이라 채용이 드물기 때문에 프로세스가 세련된 느낌은 받지 못했다. 중간 중간 질문을 하고 위키나 구글에 검색해서 확인해보는 모양이었다. 운영체제, 네트워크, 데브옵스 관련된 지식을 사전에 정리 해둔게 나름 도움이 되었다.

https://jvns.ca/zines/

https://blog.balthazar-rouberol.com/preparing-the-sre-interview

http://blog.marc-seeger.de/2015/05/01/sre-interviews-in-silicon-valley/

https://medium.com/netflix-techblog/netflix-at-velocity-2015-linux-performance-tools-51964ddb81cf

두번째 면접관은 중국계 매니져였다. 채용되면 boss가 될 사람이었는데 신기하게도 SK C&C를 잘 알고 있고 관련 사업들에 대해서도 궁금해 했다. 내 스마트 카드 관련 경력을 보고 자기가 적극 추천해서 진행하게 되었다는데, 그 말을 아 1차는 통과 하겠구나 라는 생각이 들었다. JD에는 써있지 않지만 스마트 카드 관련 개발을 해보았다면 애플 페이 조직은 집처럼 느껴질 것이라고 했다. 그외 질문들은 다음과 같다.

  • SRE는 업무 진행 중간에 인터럽트가 걸릴 수 있다 괜찮아?
  • 온콜에 대해서 어떻게 생각?
  • 지금 회사 뭐가 마음에 안듬?
  • SE를 사용한 모바일 월렛 거래를 그림으로 설명해 보시오
  • ISD가 다른 SD 영역에 접근할 수 있나? (스마트 카드 관련 질문)
  • 자바 해시맵 구현에 대해서 이야기 해봐
  • ECC 에 대해서 설명해봐

3시간의 인터뷰 였지만 사실 내가 예상 했던 것과는 달리 기술적인 질문들이 그렇게 전문적이진 않았다. 아마 SRE + 스마트 카드라는 특수한 조합 때문이라고 생각한다. 어쨌던 면접 본후 3일뒤 다음 면접 연락이 왔다.

애플페이 2차 면접

매니져 한명과 팀원이 2인 1조로 인터뷰를 가졌는데 매니져는 거의 대부분 인성 관련 질문을 했고 나머지 SRE는 본인도 입사한지 얼마 되지 않았다며 주로 이전 직장 관련 질문을 했다.

  • 배포 프로세스 설명해보라
  • 로그 저장, 처리에 대해서 설명해보라
  • 왜 컴퓨터 공학을 전공했나?
  • 첫번째 이직과 두번쨰 이직의 이유

몇일 뒤 미국의 시니어 매니져와 폰인터뷰를 가졌다. 번호가 표시되지 않는 페이스타임 음성 전화로 오전 9시에 40분 가량 이야기를 나눴다.

  • 여태까지 한일에 대해서 설명해봐
  • 압박을 받는 상황에서 어떻게 견디나
  • 배포나 모니터링할때 사용하는 툴에 대해서 설명해봐
  • ECC RSA의 차이점에 대해서 말해봐
  • CSR에 들어가는 제일 중요한 정보는?

전형적인 미국 쿨가이 였는데, 애플에 다니는 것이 얼마나 좋은지에 대해서 장황하게 설명했다. 애플 유니버시티가 있는데 그곳에서 노벨상 수상자의 강연을 듣기도 하고,, 여러가지 자랑(?)을 많이 했는데 확실히 동기부여가 되긴 했지만, 역시 일본지사와 미국본사의 차이는 어마어마 했음을 이때는 못느끼고 있었다. 이부분은 뒤에 후술함. 모든 기술적인 질문에 대답하지 못한건 없어서 나름 좋은 결과를 기대했다.

다음 주 화요일에 바로 응답이 왔는데 토요일날 면접을 본 시니어 매니져의 피드백이 전만큼 좋지 않다는 것이었다. (unfortunately, his feedback is not as positive as previous sessions).

하아, 당연히 합격이라고 생각하고 있었는데 이렇게 결과가 나오니 당황스러웠다. 하지만 아직 최종 결과가 나온건 아니라고 하니 불행중 다행이었지만 정말 면접은 아무도 모른다는 생각이 들었다.

애플 페이 3차 면접

그렇게 8일 정도가 지나니 갑자기 코디네이터 로부터 다음 면접에 대한 연락이 왔다. 하아, 애플,, 이렇게도 막무가내라니.. 그래도 연락이 온건 기쁜 일 이었기 때문에 다음 면접을 준비했다.

첫번째는 영국에 있는 SRE, 두번째는 미국에 있는 SRE 와 면접을 보았다. 관련 질문은 거의 첫번째 면접에서 물어봤던 기본적인 운영체제와 네트워킹 관련된 질문이 주를 이뤘고 개발철학, 쉘언어와 스크립트 언어중 선호도를 묻는 질문들이 이어졌다. 다분히 뭔가 정리되지 않은 느낌이 들었는데, 보통 3차 면접이면 임원이라고 생각하고 면접에 임했기 때문에 처음에는 약간 당황해서 헛발질을 했다. 영국이라 전화가 잘 들리지 않았기도 했고.. 어쩃던 각 40분씩 인터뷰를 2회 거치고 다음 연락을 기다리게 되었다.

애플페이 4차 마지막 면접

거의 20일이 지나서야 애플로 부터 연락이 왔는데 1차 면접에서 본 중국인 매니져와 다시한번 30분간 면접을 볼 수 있냐고 물어보았다. 여기까지 왔는데 안될게 있나.. 몇일 뒤 싱가폴 출장중의 중국인 매니져와 면접을 보았는데, 질문들이 조금 이상했다. 하청업체하고 일을 해야할 수도 있는데 일본어로 지시를 내릴 수 있을까? (일본어로 테스트 케이스를 작성해야 하는 이유에 대해서 설명.) 데이터 베이스 문제 해결방법, 스마트카드 관련 질문등.. 전혀 종잡을 수 없는 질문들을 물어보았다. 다른 인터뷰어들도 맘에 들어했다고 하는데, 한 미국인 매니져는 영어가 조금 부족한 것 같다는 피드백을 했다고 한다. 하지만 중국인 매니져의 영어도 그렇게 뛰어난 것은 아니었기 때문에 , 어차피 근무지가 미국도 아니고, 그래서 최종까지 보게 된 것 같았다.

결과

다시 20일(!) 정도가 지나서 결과를 받을 수 있었는데, 탈락이었다.  연락도 잘 안하던 리크루터가 그동안 애쓴것이 짠했는지 구구절절 이유를 설명해 주었다.  기술적 능력과 잠재력은 높이 평가했지만 최근에 해당 포지션의 JD가 바뀐것이 주된 이유였다. (Even though all members with whom you spoke very highly evaluated your technical skills and great potential, the JD had recently evolved into SRE+Project Manager+Quality Engineer hybrid role ).

결국 마지막에 프로젝트 관리와 관련된 질문은 그것 때문이었다.

총평

역시 실리콘밸리 회사도 아시아에서는 지사일뿐 이라고 느껴졌다. 특히 구글이나 아마존, MS처럼 자체 개발센터를 두지 않는 이상 일본이나 한국 오피스는 연락 사무소 정도 역할을 하게 되는 것 같다. 실리콘밸리 SRE가 프로젝트 관리나 QA까지 책임지지는 않을 터이니,, 복지나 연봉적인 측면에서도 차이가 분명히 있고 (그래도 일본애에서는 분명히 최상급 이었을테지만), 입사 후에 업무로 봤을떄도 확실히 미국 본사가 훨씩 핵심에 가까운 업무를 하고 있는 것 같았다. 물론 일본 애플도 통과 못한 실력으로 본사를 가긴 힘들겠지만,, 마지막에 JD가 바뀌어서 탈락했다는 사실은 그나마 작은 위안이 되어준다. 아직 프로젝트 관리나 QA업무를 하고 싶지는 않았기 때문에..

SRE (Site Reliability Engineering) 를 읽고나서..

http://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X

올해 출판된 책인데, 내용이 괜찮아서 번역되기 전에 원서로 읽고 간단히 정리함.

Preface

  • SE (Software Engineering) 와 아이를 가지는 것의 공통점은 탄생전의 노력도 힘들고 고통스럽지만, 출산 후에 들어가는 노력과 정성이 더 크다는 것이다.
  • 전체 소프트웨어 라이프 사이클의 40%~90% 의 노력이 개발 후에 발생한다.
  • 배포되고 운영되는 소프트웨어를 안정적이라고 간주하는 것은 틀렸다
  • SE는 주로 디자인과 개발에 초점을 두는 경향
  • 개발에서 – 배포 – 운영까지 모든 생명주기를 다루는 규칙이 필요
  • 이런 규칙은 보다 넒은 기술셋을 요구하고 다른 종류의 엔지니어와는 조금 다른 관심사를 가진다 – 이런 discipline 을 SRE라고 부른다.

Introduction

  • 전통적인 SysAdmin 은 개발자에 비해서 Operational 한 기술셋을 요구함
    • SysAdmin 의 장점
      • 구현이 쉬움, 다른 유사산업(건설?)에서 예제들을 가져다 쓸 수 있음
      • 관련 스킬 보유자를 찾기 쉬움
      • 기존 도구 & 서비스 제공업체 들이 이미 존재 해서 새로운 도구 개발 필요없음
    • 단점 (개발과 운영을 분리 했을 시)
      • 직접 비용 발생
        • 서비스가 커지면서 변경이 일어나거나 이벤트 발생시에 수동으로 대처하는 방식으로는 많은 인원을 필요로함 -> 비용증가
      • 간접 비용 발생
        • 두팀의 기술셋과 동기, 백그라운드가 다르다는 사실
        • 각자다른 리스크 인식, 해결방안, reliability 에 대한 개념
    • 개발팀은 빠른 기능추가를 원함 ,운영팀은 문제가 없기를 바람람
    • 두팀의 목표가 상이함함
  • 구글은 이런 문제에 SRE 라는 다른 접근 방식을 취함함
  • 간단하게 설명하면 SRE는 개발자 출신의 운영팀
    • 크게 두가지로 분류됨
      • 60%는 구글 Software Engineering
      • 40%는 개발자 역량으로는 조금 부족하지만 다른 전문성을 가진사람 (주로 유닉스와 네트워킹)
    • 근무 시간의 50%는 운영, 50%는 개발에만 씀
    • 채용이 힘들다
  • SLO (Service Level Objective)
    • 사용자는 100%나 99.99%의 Availability 나 차이를 못 느끼기 때문에 100%를 목표로 잡는 것은 잘못 됨
    • 다른 요인으로 인해 100%가 될수도 없음 (네트워크 유실 등)
    • Target Availability 는 반드시 있어야 함
    • 99.99%의 Availability 를 가진다면 0.01% 의 Error Budget 을 가짐짐
    • 이 Error Budget 을 활용하면 SRE팀과 개발팀의 목푤르 일치 시킬 수 있음음
      • Error Budget 내에서 더 빠른 기능 개발 및 배포
  • 모니터링
    • 전통적인 system Metric 에 의한 alert은 잘못된 것임.
    • 인간이 해석을 하는게 아니라 컴퓨터가 해석을 하고 사람은 행동여부만 결정해야 함
      1. alert
      2. ticket
      3. logging
  • 변경관리
    • Progressive roll out
    • 빠르고 정확하게 문제 찾기
    • 문제 발생시 안전한 롤백
  • 수요조사
    • Organic Growth (서비스 런칭 후 자연스러운 증가)
    • Inorganic Growth (새로운 기능 추가 등으로 인한 증가)
  • 프로비져닝

2. Google Production Environment

  • pass

3. Embracing Risk

  • Extreme reliability comes at cost
    • 사용자경험(UX)이 네트워크나 디바이스 같이 less reliable 한 컴포넌트들에 의해 주도되기 때문
  • reliability 를 늘리는 비용은 not linear 이고.. 100x의 비용이 들어감
    • 유후장비에 대한 Cost (cost of redundant machine)
    • 기회 비용 (opportunity cost)
    • 최대한 reliable 하게 만들돼 필요이상은 아님 (no more reliable than it needs to be)
  • 리스크 측정 (Measuring risks)
    • 대부분의 서비스에서 risk tolerance (받아 들일 수 있는 리스크)는 계획되지 않은 다운타임 (unplanned downtime)의 허용시간과 동일
      • Unplanned downtime 은 99.99 와 같이 뒤에 붙는 9의 숫자로 표현될 수 있다.

        Availability = uptime / (uptime + downtime) e.g) 99.99% Availability 는 년간 52.56 분의 downtime 을 의미함

    • 그러나 Google 과 같이 Globally 서비스 하는 회사는 위 값이 의미가 없다
      • 그래서 request success rate 를 사용

        Availability = successful requests / total requests

    • daily 2.5M 요청을 처리할 경우 99.99%의 가용성은 하루에 250 errors 를 의미한다
  • 서비스의 Risk tolerance 알아내기
    • 다음과 같은 Factor 를 사용
      • 필요로 하는 Availability level . 다음과 같은 기준으로 정한다.
        • 사용자의 기대 Level
        • 매출과 즉결되는가?
        • 유료인가 무료인가
        • 시장에 경쟁서비스가 있는가? 그 경쟁상대의 레벨은?
        • 기업고객 대상인가 일반고객 대상인가
      • 종류가 다른 장애는 서비스에 미치는 영향도 다른가?
        • 이미지가 늦데 로딩되는 것과 개인정보가 유출되는 장애는 수준이 다름

4. Service Level Objective

  • SLI (Service Level Indicator)
    • request Latency
    • error rate
    • system throughput
    • Availability
  • SLO (Service Level Objective)
    • SLI < 목표 & lower bound < upper bound

5. Eliminating Toil

  • 구글에서 SRE는 Operational Work 보다 장기 엔지니어링 프로젝트에 시간을 쏟길 원한다. Operational work 는 종종 오해되서 Toil 로 대체해서 사용한다
  • Toil (잡일) 정의하기
    • Manual
      • 예를들어 어떤 작업을 자동화한 스크립트를 사람이 수동으로 돌리는 것
    • Repetitive
    • Automatable
    • 태스크 종료후에도 똑같은 상태일 경우
    • O(n) 으로 증가할 경우
  • SRE 는 50% 이하의 시간만 Toil (잡일)에 쓰고 나머지 시간은 Toil 을 제거하는 일에 쓴다
    • 이 잡일들을 빨리 제거하지 않으면 곧 일의양이 늘어나고 모든 사람들의 시간을 100% 소비하게 된다
      • SRE 채용시에도 분명히 알려줌. 단순 운영업무가 아니다
    • 잡일은 항상 나쁜가?
    • 규모가 작을때는 그렇지 않을 수도 있다. 그런종류의 일에서 성취감을 느끼고 , 좋아하는 사람들도 있음음.
    • low risk , low stress
    • 양이 많아지면 그사람의 커리어 자체를 위협

6. Monitoring Distributed system

  • 구글에서 사용하는 용어
    • 화이트박스 모니터링
      • JVM 메트릭이나 내부 시스템 정보를 사용한 모니터링
    • 블랙박스 모니터링
      • 외부에서 사용자의 시선으로 모니터링
    • 대시보드
      • 서비스의 핵심 지표를 보여주는 웹 애플리케이션
  • 4가지 중요 지표
    • Latency
      • 성공한 요청과 실패한 요청의 latency 를 섞지 마라라
      • Slow error 는 Fast error 보다 나쁘다
    • Traffic
      • 시스템 별로 조금씩 측정기준이 다를 수 있다
      • 웹서비스의 경우 초당 http request
      • 오디오 스트리밍의 경우 동시 세션수나 네트워크 량
    • errors
      • 요청당 에러 비율
      • 500 or 200 이지만 비정산 응답을 모두 카운팅
    • Saturation
      • 시스템의 포화도

7. Evolution of automation at Google

  • 자동화의 가치
    • 일관성 (Consistency)
    • 확장 가능한 플랫폼으로 커질 수 있다
      • 플랫폼화 되면 버그나 실수들도 쉽게 관리가 되고 동시에 처리 가능능
    • Faster Recovery
    • Faster Action
  • automation
    • 소프트웨어 위에 동작하는 소프트웨어. Meta SW
    • 예제..
      • 사용자 계정 생성
      • 클러스터 구성
      • 소프트웨어설치
      • 서비스 롤아웃
      • 실시간 설정 변경