현재 플레이오토에서 컨테이너를 프로덕션에서 운영하기 위해 ECS와 AWS 서비스들을 어떻게 활용했는지를 담았습니다.

1. 플레이오토 ECS 사용사례
ft ECS 어디까지 써봤니?
zkmm234@gmail.com

4. 개요
1.기존의 인프라
2.컨테이너 도입의 계기
3.ECS 사용경험
4.겪었던 이슈
5.얻었던 이점

5. •=

6. AWS Elastic Beanstalk
Host
OS
Language interpreter
Application server
HTTP server
Code

7. AWS Elastic Beanstalk
배포
모니터링
인프라 구성

8. 평화롭던 어느날....

9. 반복되던 일상

10. 쌓여있는 인프라(레거시)

11. 너무 쉬움

12. 5분만에 끝

13. 고통의 시작
.
?
?

14. 늘어만 가는 비용
??..

16. Immutable Infrastructure

19. 컨테이너 오케스트레이션
•클러스터링
•스케줄링
•서비스 디스커버리
•로깅 및 모니터링
•기타 배포 등등..

22. ECS 구성요소
•Container Instance (EC2)
•Task ( 어플리케이션 컨테이너의 집합 )
•Task definition ( 컨테이너 집합의 사전 명세서 )
•Service ( task 갯수 유지 )
•Cluster ( Container Instance 집합 )

24. 컨테이너 오케스트레이션
•클러스터링 => ECS
•스케줄링 => ECS
•서비스 디스커버리 => Route 53
•로깅 및 모니터링 => cloudwatch
•기타 배포 등등..

25. 1. 클러스터링

27. 1. ECS agent
•"NetworkMode": “host",
•

28. 1. ECS agent
•
•ecs.config 파일을 ECS agent 환경변수로 담아준다
•https://docs.aws.amazon.com/ko_kr/AmazonECS/
latest/developerguide/ecs-agent-config.html
•https://github.com/aws/amazon-ecs-agent

29. 1. ECS agent
•클러스터링의 핵심
•해당 설정을 미리 잘해두는게 중요함
•ECS의 지원기능을 파악하기 쉽다
•컨테이너 관리 및 옵션들을 제공해주는 기능으로 판단하면 됨

30. 2. 스케줄링
•Replica => 그냥 갯수 맞춰서 띄워줌
•Daemon => 노드마다 하나씩 다 띄워줌
•Schedule => 일정시간 마다 실행해줌

31. 2. 스케줄링

32. 2. Soft limit, Hard limit

33. 2. 배치 제약과 전략
•제약 (task)
•노드에 대한 조건을 제시할 수 있다.
•Ex) t 타입에만 실행하라, m 타입에서는 실행하지 마라
•전략 (service)
•노드에 대한 조건보다 더 추상적(spread, random,
binpack)
•Ex) az에 골고루, node 하나씩 가득 채우면서 진행하라

34. 2. 배치 옵션
•ecs.ami-id
•ecs.availability-zone
•ecs.instance-type
•ecs.os-type

37. 2. Fargate
•장점
•배치와 클러스터링의 관리 요소가 없어짐
•오토스케일링의 관리가 훨씬 쉽고 빠르다 (인스턴스 부팅 시간 필요
x)
•단점
•EC2의 비용 관리 옵션 사용x
•컨테이너 안에 들어가서 테스트 불가
•관리형이라서 log나 volume을 자유롭게 가져가지 못함

38. 3. 서비스 디스커버리

39. 3. 서비스 디스커버리
•SRV 레코드
•default
•A 레코드
•Network 를 awsvpc 모드로 사용해야됨

40. 3. 서비스 디스커버리
•ENI 는 AWS 에서 사용하는 가상 네트워크 인터페이스
•EC2 하나에 한개의 ENI가 할당되는게 일반적
•이것을 task(컨테이너집합)에 할당하는것
•EC2와 ENI의 limit 을 고려

41. 4. 로깅 및 모니터링

42. 4. 로깅 및 모니터링

43. 4. 로깅 및 모니터링

44. 4. 로깅 및 모니터링

45. 4. 로깅 및 모니터링

46. 겪었던 이슈

47. 1. ECS agent 종료 이슈
•어느 순간 agent 연결상태가 fail 됨…
•해당 컨테이너 인스턴스 통제가 안됨
•알고보니 agent 가 죽었다.
•그 이유는 과도한 컨테이너 밀집

48. 1. ECS agent 종료 이슈
•ecs agent config를 통해 작업 메모리 할당이 안되게 미리 총
메모리 양을 줄일 수 있다.
•ECS_RESERVED_MEMORY
•시스템 메모리까지 고려해서 넉넉히 확보해 두자

49. 2. 컨테이너 오류 추적
•컨테이너가 갑자기 죽는 경우 그 사실을 인지하는 과정이 꽤
오래 걸림.
•로그나 event를 계속 내가 감시할 수가 없음.
•그리고 죽은 task의 로그를 elasticsearch에서 찾기가 어렵다.

50. 2. 컨테이너 오류 추적
•알림이 필요함

51. 2. 컨테이너 오류 추적
•ECS agent가 api를 제공함
•/v1/metadata
•/v1/tasks
•https://docs.aws.amazon.com/ko_kr/AmazonECS/
latest/developerguide/ecs-agent-introspection.html
• task elasticsearch log

52. 3. thin pool 부족
•특정 호스트에서 task가 뜨질 않음
•사유를 보면 image pull에서 500 에러로 실패
•실제로 해보면 디스크 공간 부족처럼 에러가 뜨는데
•디스크 공간이 부족하지 않음(df -h)

53. 3. thin pool 부족

54. 3. thin pool 부족
•Kernal parameter로 dm.min_free_space 값 조정
•전체 디스크 공간을 키움
•

55. 3. thin pool 부족
•ECS config 에 두가지 변수가 있다.
•ECS_IMAGE_CLEANUP_INTERVAL
•ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION
•이미지와 컨테이너 정리를 해주자

56. 얻었던 이점

57. 1. 자원 효율성 강화

58. 1. 자원 효율성 강화

59. 2. 손쉬운 인프라 구축

60. 2. 손쉬운 인프라 구축

61. 3. 마이그레이션의 용이성
M5 cluster R5 cluster

62. 3. 마이그레이션의 용이성
•새 EC2 인스턴스를 클러스터에 추가해준다
•기존 EC2를 한대씩 내리면서 task를 내렸다 올렸다를 반복한
다.
•마지막에 고른 분포를 위해 재배포 한번 해준다.

63. 3. 마이그레이션 용이성
•Spot Instance와 궁합이 잘맞다.

64. 4. 도입하기 쉬워서 금방한다

65. 배포는 다음 기회에..

66. Q&A

67. 감사합니다