Recommended
Recommended
More Related Content
Similar to Multitasking on DB and Django
Similar to Multitasking on DB and Django (20)
Multitasking on DB and Django
- 1. PyConKorea2019 Multitasking on DB and Django Multitasking 환경을 상대하기 위한 DB의 특성과 그런 DB를 상대하기 위한 Django
- 2. DB Locktimeout으로 고생하고 있는 peoplefund RepaymentProcessSystem 개발자 문석환 누구신가요? seokhwan@peoplefund.co.kr
- 3. singletasking인 이런 시절도 있었지만… MultitaskingSystem https://oldpc.tistory.com/17
- 4. 요즘은 이런 작은 제품도 multitasking이 가능한 시스템을 갖고 있음 MultitaskingSystem https://learn.adafruit.com/introducing-the-raspberry-pi-zero
- 5. local시스템에서도 multitasking을 지원하는 요즘, 웹 서비스에서의 multitasking은 필수 구성요소 MultitaskingSystem
- 6. 여러 process가 공유된 자원에 의존할 경우 race condition이 발생 RaceCondition http://extmovie.maxmovie.com/xe/movietalk/30925104
- 7. 웹 서비스에서 DB가 대표적인 예 • lock timeout이라는 오류를 쉽게 볼 수 있음 RaceCondition http://extmovie.maxmovie.com/xe/movietalk/30925104
- 8. 동시다발적인 request가 하나의 공유된 자원인 DB에 접근하게 될 경우 locktimeout이 발생할 수 있음 DebuggingLockTimeout
- 9. 동시다발적인 request들의 상관관계는 local 디버깅 툴만으로는 확인이 어려움 DebuggingLockTimeout
- 10. 이론을 바탕으로 한 눈버깅이 필요 DebuggingLockTimeout https://www.monster.com/career-advice/article/open-source-coding-can-give-your-career-an-edge
- 12. 공유된 자원인 DBMS가 동시다발적인 요청을 안정적으로 처리하기 위해 갖고 있는 특성들 • Django에서 이 특성들을 어떻게 활용할 수 있는가? PurposeofThisSession
- 13. DBMS는 데이터의 일관성을 지키기 위해 transaction과 ACID라는 특성이 존재함 DBandConcurrentProcesses
- 14. transaction은 여러 작업(operation)들의 set • DB operation의 기본 단위 Transaction READ(balance) ADD 1000 ON balance WRITE(balance) transaction
- 17. transaction의 모든 작업들이 모두 반영(commit)되거나 아예 반영되지 않고 원상복구 되는(rollback) 특성 ACID - Atomicity WRITE(A) WRITE(B) transaction
- 19. 미리 정의된 규칙에 의해서만 데이터 수정이 가능한 특성 ACID - Consistency
- 20. 예를 들어 Null 값이 들어갈 수 없는 column에 Null 값을 추가하려 할 경우 DBMS가 에러를 발생 ACID - Consistency
- 22. 특정 transaction(T)에서 진행한 작업들이 다른 transaction(Q)에게 보여지는 정도를 나타내는 특성 ACID - Isolation
- 23. isolationlevel이 높으면, 하나의 transaction(T)이 변경한 데이터를 (T의 commit이 일어나기 전까지)다른 transaction들은 볼 수 없음 ACID - Isolation
- 24. isolationlevel에 대해서는 후반부에 더 자세히 설명 • isolation level은 transaction들 사이의 특성 ACID - Isolation
- 26. 한번 반영된 transaction은 (시스템이 crash 되어도) 영구히 적용 되어있는 특성 ACID- Duration
- 28. multitasking 환경에서 여러 작업들이 동시다발적으로 진행된다고 하지만 ConcurrentTasks
- 29. (CPU한 개 기준)한 시간대에는 하나의 작업만이 진행됨 ConcurrentTasks
- 30. 여러 작업들이 한 줄로 cpu를 사용하기 위해 기다림 ConcurrentTasks http://nyclovesnyc.blogspot.com/2013/09/iphones-5c5s-launch-draws-record-crowds.html
- 31. 동시에 같은 계좌에 입출금이 발생하는 경우 ConcurrentTasksandData
- 32. ConcurrentTasksWithoutLock READ(BALANCE) READ(BALANCE) 입금 WRITE(BALANCE) WRITE(BALANCE) 1000 1000 + 1000 2000 BALANCE 출금 1000 2000 0 1000 1000 - 1000 0 1000
- 33. 눈 뜨고 돈이 사라지는 마법을 경험 ConcurrentTasksandData http://egloos.zum.com/galaon/v/5355771
- 34. ConcurrentTaskswithLock READ(BALANCE) 입금 WRITE(BALANCE) 1000 1000 + 1000 2000 READ(BALANCE) WRITE(BALANCE) BALANCE 출금 1000 2000 1000 2000 2000 - 1000 1000 2000 READ(BALANCE) wait
- 35. lock을 이용하면 데이터를 더 안정적으로 다룰 수 있음 ConcurrentTasksandData
- 36. DBMS에는 두가지 종류의 lock이 존재 DBMSLockTypes
- 37. writelock • 같은 데이터에 write를 시도하는 다른 transaction을 block • 같은 데이터에 read를 시도하는 다른 transaction을 block DBMSLockTypes https://www.writerswrite.com/writingmemes/
- 38. readlock • 같은 데이터에 write를 시도하는 다른 transaction을 block • 같은 데이터에 read를 시도하는 다른 transaction을 허용 DBMSLockTypes https://memeshappen.com/meme/oh-no-meme/what-i-have-to-read-62306
- 39. 안정적인 데이터의 관리를 위해 DBMS는 lock의 사용법에 대한 protocol도 정의 TwoPhaseLockingProtocol
- 40. ExpandingPhase • lock을 얻을(acquire) 수는 있지만 놓을(release) 수는 없는 상태 TwoPhaseLockingProtocol
- 41. ShrinkingPhase • lock을 놓을(release) 수는 있지만 얻을(acquire) 수는 없는 상태 TwoPhaseLockingProtocol
- 42. transaction이 lock을 사용하기 위해서는 두 단계 중 하나에 속해야 함 TwoPhaseLockingProtocol
- 43. transaction이 하나의 lock을 놓게 되면 모든 lock들을 놓을 때 까지 새로운 lock을 얻을 수 없음 TwoPhaseLockingProtocol https://cheezburger.com/9344072192
- 44. 일반적으로 transaction은 expandingphase로 시작해서 commit/rollback후 shrinkingphase로 돌입해서 lock을 모두 놓게 됨 TwoPhaseLockingProtocol
- 45. lock은 조심히 다뤄야 할 대상 DownsideofLock https://makeameme.org/meme/look-locks-everywhere
- 46. lock은 process들이 병렬로 작업하지 못하게 함 DownsideofLock http://egloos.zum.com/kwangaeto/v/6248656
- 47. 잘못 사용할 경우 deadlock발생 DownsideofLock http://mcs109.bu.edu/site/?p=deadlock
- 49. isolationlevel은 lock을 활용해서 transaction간의 상호작용 정도를 조절 IsolationLevels
- 50. DBMS에서 발생할 수 있는 3가지 종류의 읽기 현상 ReadPhenomena
- 52. transaction(T)이 다른 transaction(Q)에서 변경한 데이터를 commit하기 전에도 읽을 수 있음 DirtyRead https://northstateparent.com/2013/01/what-to-do-when-your-child-cheats/
- 54. 두 번의 같은 query가 다른 결과값을 반환 • 예: 특정 계좌에 기록된 잔액을 두 번 조회했을 때 서로 다른 잔액이 반환 Non-repeatableRead https://www.pinterest.co.kr/pin/448741550347685706/
- 56. 두 번의 같은 query가 다른 row들을 반환 • 예: 1000원이 남아있는 계좌들의 조회 query를 두 번 실행했을 때 첫번째 계좌 리스트와 두번째 계좌 리스트가 같지 않음 PhantomReads
- 57. 다른 값을 갖고 있는 같은 row가 반환 VS같은 값을 갖고 있는 다른 row가 반환 Non-repeatable VSPhantomReads
- 58. 같은 종류의 level이어도 각 DBMS가 구현하는 방식에 따라 약간의 차이점은 존재 IsolationLevels
- 59. 따라서 Django에서 lock에 대해 이야기할 때 필요한 기본적인 내용만… IsolationLevels
- 60. isolationlevel은 read phenomena를 허용하는 정도 IsolationLevels
- 61. IsolationLevels Reads Levels Phantom Reads Non-repeatable Reads Dirty Reads Locks Serializable NO NO NO READ, WRITE, RANGE Repeatable Reads YES NO NO READ, WRITE Read Committed YES YES NO WRITE Read Uncommitted YES YES YES -
- 64. model object를 생성,삭제,변경하는 statement가 실행될 때 바로 DBquery를 발생시킴 TransactionandLockinDjango https://www.upi.com/Odd_News/2017/04/03/Hungry-cats-ring-bells-for-treats/6341491227290/
- 65. 각 statement마다 자동으로 transaction이 씌여짐 TransactionandLockinDjango https://www.upi.com/Odd_News/2017/04/03/Hungry-cats-ring-bells-for-treats/6341491227290/
- 66. Django는 기본적으로 transaction을 시작하는 api를 제공하지 않음 TransactioninDjango
- 67. django.db.transaction.atomic을 사용하여 여러 statementset에 대해서 atomicity를 보장할 수 있음 TransactioninDjango
- 70. NestedAtomicFunction 바깥쪽 transaction 시작 만약 안쪽 transaction이 실패하면 save point까지 rollback 바깥쪽 transaction이 종료되면 지금까지 작업한 전체 작업들이 commit 안쪽 transaction을 시작하기 전에 save point 생성
- 71. Django는 서버에 설정된 DBMS의 isolationlevel을 사용함 IsolationLevelsinDjango
- 72. Django에서 OPTIONS를 사용하면 서버 설정을 overwrite할 수 있음 • 1.11부터 OPTIONS에 isolation_level이라는 설정값 이름을 제공 IsolationLevelsinDjango
- 73. MySQL의 default는 RepeatableReads • Django는 Read Committed를 권장 IsolationLevelsinDjango
- 74. 주의:MySQL에서 isolationlevel은 binarylog(slave DB를 만들기 위한 log)와 밀접한 연관이 있음 BewareI https://www.memedroid.com/memes/detail/93889
- 75. Django와 MySQL의 isolation level을 다르게 설정할 경우 lock이 생각과 다르게 동작할 수 있음 BewareI https://www.memedroid.com/memes/detail/93889
- 76. isolationlevel의 설정에 의해 각 statement들은 자동으로 read/writelock이 사용됨 LockinDjango
- 77. 임의로 lock을 발생시켜야 할 경우 transaction.atomic 이후 select_for_update 함수를 사용할 수 있음 LockinDjango
- 78. 주의:select_for_update를 select_related와 함께 사용할 경우 join걸린 모든 row에 lock이 발생 BewareII https://www.ytn.co.kr/_ln/0109_201512051510331549
- 79. 주의:연관된 모델들의 경우 lock의 순서를 정해야 deadlock을 회피할 수 있음 BewareIII
- 80. 예: lock이 필요할 경우 무조건 T1 - T2 - T3 순서로 lock을 얻기 BewareIII
- 81. 주의:너무 많은 데이터가 한번에 만들어 질 경우 auto increment에 의해 프로세스가 lock을 기다리는 현상이 발생할 수 있음 • 참조: InnoDB의 AUTO_INCREMENT BewareIV https://www.reddit.com/r/funny/comments/60dpn7/beware_of_cat/
- 82. atomic과 select_for_update를 사용하면 Django에서도 임의로 racecondition을 컨트롤 할 수 있음 Usage
- 83. 단 너무 많이 사용할 경우 실제 서비스에서는 locktimeout을 쉽게 만나볼 수 있음 Usage
- 84. locktimeout을 피하기 위해서는 process들이 lock을 들고 있는 시간을 최소화 해야 함 Usage http://www.womennews.co.kr/news/articleView.html?idxno=58436
- 85. 주의:lock은 가장 바깥쪽 transaction이 끝나야 release됨 BewareV https://imgflip.com/i/1gfgj6
- 86. Usage