'전체 글'에 해당하는 글 2272건

 

eks-vcpu-memory

 

EKS Fargate 를 기본사양으로 약 1달 정도 사용해 봤다. Fargate 의 기본사양(최소사양)은 vCPU 0.25 / memory 0.5GB 이다. 1개의 CPU 코어가 2 vCPU 니까 0.25면... Spring Jar 파일 돌리는데 부팅시 스프링 로그가 2초에 1줄 정도씩 나왔나. 당연히 부팅시간도 상당히 늘어난다. ALB 의 health check 도 길어지고... 부팅된 후에는 Lazy 설정 때문에 Slave DataSource 가 처음 세팅될 때도 10초 이상의 응답으로 Timeout 이 발생하기도 했다. 그것 빼고는 단일 어플리케이션 돌아가는데 큰 문제는 없어보였다. 이것저것 다 빼다보면 어디다 써야할지... t2.nano 보다도 낮은 사양... 우선 xms / xmx 을 확인해 봤다.

 

public static void main(String[] args) {
    int mb = 1024 * 1024;
    MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
    long xmx = memoryBean.getHeapMemoryUsage().getMax() / mb;
    long xms = memoryBean.getHeapMemoryUsage().getInit() / mb;
    logger.info("xms: {}", xms);
    logger.info("xmx: {}", xmx);
}

// print
xms: 8
xmx: 123

 

오마이... 저런 단위는 처음보는 수치이다. 이 상태로 잘도 돌아갔다. 일단 컴퓨팅 사양부터 높였다.

 

vCPU 1개(1000m) 당 : 월 $1.2
memory 1GB 당 : 월 $1.3

 

pod 를 정의한 deployment yaml 파일에서 cpu 와 memory 를 수정하였다.

 

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

 

$ vi my-deployment.yaml
...
spec:
  containers:
  - name: web
    image: 1234567890.dkr.ecr.ap-northeast-2.amazonaws.com/web:latest
    resources:
      limits:
        cpu: 1
        memory: 2048Mi
      requests:
        cpu: 1
        memory: 2048Mi

$ kubectl describe pods podname -n mynamespace
...
Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB

 

재배포하였으나 cpu / memory 는 변경되지 않았다. 어딘가에 제한이 걸려있는 느낌.

 

LimitRange 를 사용하여 namespace 레벨에서 cpu 와 memory 를 설정해 보았다.

 

$ my-usage-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: low-usage-range
spec:
  limits:
  - max:
      cpu: 2
      memory: 4G 
    min:
      cpu: 1
      memory: 1G
    type: Container
    
$ kubectl apply -f my-usage-range.yaml -n my-namespace

 

다시 재배포해보니 잘 바뀌었다.

 

$ kubectl describe pods podname -n mynamespace
...
Annotations:          CapacityProvisioned: 1vCPU 3GB
...
    Limits:
      cpu:     1
      memory:  2048Mi
    Requests:
      cpu:     1
      memory:  2048Mi

 

뭔가 바뀌었지만 memory 2048Mi 를 설정했는데 3GB 로 세팅됐다. Fargate 는 각 pod 의 메모리 예약에 256MB 를 추가하기 때문에 기본 단위상 1G가 더 늘어났다. 256MB 를 제외하고 1792Mi 로 설정하면 2G로 뙇!

 

Dockerfile 에 Xms / Xmx 설정도 뙇!

ENTRYPOINT ["java","-Xms1024m","-Xmx1792m","-jar","/app.jar"]

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

io 도메인

Daily/Prog 2022. 1. 24. 00:27

얼마전 도메인이 세개 정도 필요해서 간만에 쇼핑 좀 했다. example.com / example.net 나머지 하나는 뭘로 선택할까... 하다가 구글 검색에 자주 보이는 io 도메인으로 결정했다. 대충 뭐 IT 기술 관련 도메인으로 많이 사용하는 줄로 알고 있긴 했는데 가격이...

 

io_domain

 

AWS 기준으로 닷컴이 $12 인데 io 도메인이 $71 라니... 구글이 $60 로 나오는데 그렇다 해도 .com 의 5배.

 

어이가 좀 없긴 했는데 궁금하기도 하여 검색을 좀 해봤다.

 

.io 도메인은 기술기반 스타트업들이나 블록체인 프로젝트에 많이 사용한다. 원래 영국령 인도양식민지(British Indian Ocean Territory)의 국가코드 톱 레벨 도메인으로 한국의 .kr 도메인과 같지만 .io 도메인은 국가 제한이 없는 누구나 사용이 가능할 수 있는 도메인 중 하나이다. 데이터 입출력을 뜻하는 Input/Output 으로도 해석하며 IT 기술기반 업계에서 많이 쓴다고 하는데 그냥 갖다 붙인 느낌... 어쨌든 한참을 그런 업계에서 애용하고 있다니 원한다면 .io 든 .dev 든 사면 되겠지만 가격이 왜 이 모양인지... 비싼 이유를 좀 찾아보려 했으나 해당 글도 별로 없는거 같고 찾고 싶지도 않아졌음. 보아하니 유행 살짝 타니까 돈 좀 벌어볼라고 세계적으로 가격단합 중인거 같은데... 비쌀땐 안사면 됨. 도메인은 .com 이 짱이지...ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

EKS 무중단 배포

Server/AWS 2022. 1. 11. 19:57

 

$ kubectl get pods -o wide -w -n exapi
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE                                                     NOMINATED NODE                                READINESS GATES
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          1s      <none>        <none>                                                   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     ContainerCreating   0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          100s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          101s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          102s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          2m11s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          1s      <none>        <none>                                                   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-6889b9d9d8-8n2mf       0/1     ContainerCreating   0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          85s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          86s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          87s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          116s    10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1

 

자알 돌아간다~ 정상적인 것처럼 보이나...

 

 

 

Default 값을 믿고 열심히 삽질해 준 나에게 감사한다.

 

Rolling Update 시 가장 먼저 선행해야 할 것은 strategy 명시이다. 기본값으로 테스트하겠다고 이 부분을 생략한게 큰 타격이 됐다.

 

$ my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: exapi
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0         # 0 fast
      maxUnavailable: 1   # 0 slow

 

maxSurge 와 maxUnavailable 값은 배포시 최대 생성 pod 수와 종료 수를 명시할 수 있다. 각각 0/1, 1/0 으로 설정할 경우 running 상태 이후에 terminating 을 시키느냐, pending 과 동시에 terminating 을 시키느냐의 차이이며 약 30초 정도의 차이를 확인했다.

 

겉보기에는 잘 작동하는 것처럼 보이나 배포시 약 5~10초간 502 Gateway Error 뒤에 504 Gateway Time-out 이 발생한다. 우선 502 에러가 발생하는 시점을 찾아봤다.

 

쿠버네티스에서 kubectl rollout restart 명령으로 배포할 경우, 새 pod 가 추가되고 Running 상태가 되면 기존 포드가 삭제되는 식이다. 확인 결과 pod 가 Terminating 되는 순간에 502 에러가 발생했다. ALB 의 Target 이 동시에 draining 되는 시점이기도 하다. 인터넷을 후벼파서 결과, 502 에러를 최소화 할 수 있는 방법을 찾아 결국 해냈다.

 

 

 

502 Gateway Error / 504 Gateway Time-out Error 최소화

 

1. ingress : connection-draining 설정

 

ALB 에 connection-draining 관련 옵션을 주어 기존 연결에 대한 처리를 유지한다. (이미 기본값으로 동작중. 효과없음.)

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  ...
  annotations:
    ...
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "30"

 

 

2. pod : readiness-gate 설정

 

readiness-gate 옵션을 활성화 하여 새로운 target 이 healthy 상태로 연결되기 전까지 기존 target 을 종료하지 않음. (마찬가지로 502 에러는 발생하나, ALB 내의 target 이 healthy 상태가 한개도 유지되지 않는 어이없는 상황은 막을 수 있음). 반드시 필요!

 

$ kubectl label namespace {mynamespace} elbv2.k8s.aws/pod-readiness-gate-inject=enabled

 

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
  template:
    spec:
      containers:
      - name: api
      readinessGates:
      - conditionType: target-health.alb.ingress.k8s.aws/api-ingress_api-nodeport_80

 

readiness-gate 옵션을 활성화할 namespace 에 레이블을 설정하고, target-health.alb.ingress.k8s.aws/{ingress-name}_{service-name}_{port} 를 위처럼 삽입한다. 설정이 올바르지 않으면 ALB 에서 target 그룹을 인식하지 못할 수도 있으니 주의!

 

 

3. pod : preStop 설정

 

life-cycle hooks 에서 pod 가 중지되기 전에(preStop) 딜레이를 가지며 기존 연결을 마저 처리한다. 새로운 연결이 이루어지지 않는다. (인터넷에서 좋아요도 가장 많고, 실제로 preStop 설정만으로 502 에러를 해결하였음.)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "60"]

 

 

4. pod : terminationGracePeriodSeconds 설정

 

preStop 가 실패했을 때 대신 컨테이너를 종료시킨다. (preStop sleep 값보다 +10초 정도로 설정: default 값은 45초)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: web-api
      ...
      terminationGracePeriodSeconds: 70

 

 

5. pod livenessProbe / readinessProbe 설정

 

pod 의 활성화 상태를 나타내는 livenessProbe 가 실패하면 재시작 정책의 대상이 된다. pod 준비 상태를 나타내는 readinessProbe 가 실패하면 해당 pod 는 모든 엔드포인트에서 제거된다. (두 방법 모두 비정상 pod 에 연결을 못받게 하여 502 에러를 줄인다고는 하는데 효과는 잘 모르겠음.)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
      ...
        livenessProbe:
          httpGet:
            path: /
            port: 80
          periodSeconds: 4
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 10

 

 


 

정리

 

이 5가지 설정 중 3가지를 사용하여 무중단 배포를 완벽하게 해결했다.

 

preStop
readinessGates
terminationGracePeriodSeconds

 

readinessGates 설정을 가장 먼저 한 바람에 필수요소인지는 확실치 않다. (조만간 테스트 예정)
preStop 설정으로 무중단 배포를 해결했다. (본인의 서비스와 사양에 맞는 설정이 필요할 수 있다.)
terminationGracePeriodSeconds 설정을 하지 않아도 문제는 없었다. 내 경우 기본값이 45초 만으로 충분한 듯.

 

한가지 더... kubectl rollout 으로 테스트 할 때 기존의 pod 가 원치 않는 동작을 할 수도 있다. 항상 기존 pod 는 delete 로 삭제한 후에 새로 생성하여 테스트 하는 것이 원하는 결과를 얻는데 도움이 될 것 같다.

 

무중단 배포도 안된다고 며칠을 eks 욕하고 있었는데... 정말 다행이다. ^_______________^

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

 

Oauth2.0 에서 Token 발급에 필요한 ClientId 와 SecretKey 생성하기.

 

 

ClientId

 

  • 일반적으로 길이 16~32자 16진수 문자열로 생성.
  • 모든 클라이언트에서 고유함.

 

SecretKey

 

  • 일반적으로 길이 32~64자 16진수 문자열로 생성.
  • TimeStamp / UUID 라이브러리 등은 지양.
  • 일반 암호와 동일하므로 DB 에는 암호화 되거나 해시된 버전으로 저장.

 

ClientId ex)

 

Foursquare: ZYDPLLBWSK3MVQJSIYHB1OR2JXCY0X2C5UJ2QAR2MAAIT5Q
Github: 6779ef20e75817b79602
Google: 292085223830.apps.googleusercontent.com
Instagram: f2a1ed52710d4533bde25be6da03b6e3
SoundCloud: 269d98e4922fb3895e9ae2108cbb5064
Windows Live: 00000000400ECB04
Okta: 0oa2hl2inow5Uqc6c357

 

 

Client Id / Secret Key 생성

 

commons-lang3 의 RandomStringUtils 를 사용하여 특정 길이의 랜덤한 문자열을 생성할 수 있다.

 

dependencies {
    implementation 'org.apache.commons:commons-lang3:3.12.0'
}

...

RandomStringUtils.randomAlphanumeric(32));  
// 1JhGTHmGlCP037aATyJzph983FRl5r14
RandomStringUtils.randomAlphanumeric(64));  
// 84ldr2jaagfMiIwzj2wFnaPxXBV2Yc9WC1AbJPaugEj5qHSWHkPjt2HInLdlzV7S

 

spring-security 를 사용할 경우, SecretKey 를 한번 더 암호화 하기 위해 BCryptPasswordEncoder 클래스를 사용한다.

 

PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
String encodeKey = passwordEncoder.encode(secretKey);

 

PasswordEncoder.encode 는 항상 랜덤키를 생성하기 때문에 인코딩된 결과끼리의 비교는 불가능하지만, secretKey 와 encodeKey 의 비교는 가능하다.

 

if (passwordEncoder.matches(secretKey, encodeKey)) {
    System.out.println("matching~");
}

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

2022년의 시작

Daily/Diary 2022. 1. 1. 02:10

2022years

 

피곤하다. 힘들다. 하지만 재미있고 행복하다...

 

2021년 신축년(흰소띠해)은 44살로 딱히 좋아하지 않는 숫자가 두개나 들어있는데도 나름 운이 좋은 해였다. 일단 기억나는 악재가 없었다. 수년째 그렇긴 하지만... 올초에 쓴 반성문을 보니 원룸살던 그때가 조금은... 아니 매우 그립다. 벌써 1년이 지난것도 신기하고, 지금이 한 해가 끝나는 12월 31일이 맞나 싶기도 하고... 11월부터 크런치 모드에 돌입했더니 정신을 차리기가 힘들다. 이 힘든 와중에도 결산은 해야지. 2021년의 이슈들을 한번 돌이켜 봤다.

 

 

1. 합가

 

같이 사는게 효도라고 생각하고 살림을 합쳤지만, 생각처럼 쉽지는 않았다. 혼자 살다가 다시 돌아와보니, 누군가와 함께 산다는 것은 정말 쉬운 일이 아니었다. 그 누군가가 부모님이더라도... 나를 향한 부모님의 걱정이 점점 더 커져간다. 과도한 부모 사랑이 부작용을 일으키고 있다. 하루에 부모님을 마주치는 시간도 얼마 안되는데 신기하기도 하지. 함께 살면 부모든 형제든 누군가는 참아야 하고, 누군가는 이해해야 하고, 누군가는 희생해야 한다. 가족끼리 그렇게 사는 것이 이상한 일은 아닌데... 하... 혼자 살고 싶다. 아니면 둘이... 부모님이 그립다면 자주 찾아뵈면 된다. 용돈을 더 드리면 된다. 같이 살지 않으면서도 효도할 방법은 많지 않을까. 마침(?) 3월부터는 판교로 출근을 해야 한다. 다시 한번 선택의 기로에 서야 하는 날이 머지않아 올 것 같다.

 

 

2. 이직

 

한 회사에 조용히 있으면서 6년이란 박봉의 시절을 보냈다. 이래저래 아끼고 살면 모을 수 있으니 박봉인 줄도 모르고 만족하고 살았는데, 나와보니 박봉이었다. 다행히 그 곳은 너무도 일이 없어 한가로이 보냈으니 대충 퉁이라 치자. 이직할 때 즈음에 '네카라쿠배당토' 등의 회사들과 더불어 개발자 버프가 생기면서부터 개발자들의 몸값이 많이 높아졌다. 그렇게 SI 란 생소한 직군을 선택했지만 적응하기도 전에, 또 한번의 기회가 찾아왔다. 그리고 두번의 이직 후 지금까지 크런치 모드가 이어지고 있다. 불과 1~2년 전까지만 해도 잉여시간에 무엇을 해야 할까 고민을 많이 했었는데... 물론 워라밸 좋다. 그게 사는 맛이지.  하지만 그렇게 몇년을 살았는데도 만족을 주지는 못하더라. 못가졌을 때나 갖고 싶은 거지, 가지고 나면 기존의 상상은 다 허상이 된다. 지금은 닥치고 개발이다. 그때가 굳이 노력을 하지 않아도 되는 자리였다면, 지금은 최선을 다해야 하는 자리이다. 모두의 기대가 크고, 잘하고 싶고, 잘해야 한다. 어깨가 무겁다... 털썩...

 

 

3. 운동

 

2월 쯤이었나. 집에서 맨몸으로 스쿼트 하다가 디스크가 터져서 한달쯤 고생했던 기억이 난다. 그렇게 허리 개입 운동을 피하다가 레그 컬/프레스와 익스텐션에 반해 버렸다. 하체는 물론이고 몇일을 앉아 있어도 허리에 통증이 생기지 않았다. 그걸 알게 된 순간부터 하루에 한시간씩 레그 컬/프레스, 익스텐션을 꾸준히 했다. 얼마 전까지는... 거리두기 때문에 헬스장을 못가면서 이번에는 집에서 스쿼트를 연구(?) 하다가 드디어 맨몸 스쿼트에 성공했다. 44년만에 만족스러운 자세, 느낌(?) 나옴.ㅋ 하지만 그건 몇달전 얘기고... 지금은 7시출근, 23시퇴근, 안피곤하면 홈짐 1시간. 이게 요즘 루틴이다. 주말도 여지없고. 게임에 미쳐있을 때도 눈알이 이렇게 힘들어하지는 않았었는데 지금은 눈에 좋다는 약은 다 먹고 있다. 보통 12시간은 계속 앉아서 모니터만 보고 있으니... 체력이 받쳐줘야 하는데 꾸준히 운동할 여건이 안되네. 등산은 시간도 없을 뿐더러 다치면 짤릴지도 모르니 일단 참는 중. 당분간 집에서 시간 날 때마다 홈짐으로 몸만 풀기로.

 

 

4. 연애

 

작년 사주풀이에서 2022년에 결혼운이 있다길래 용기내서 한번 찔러봤는데 역시나... 꽝이었다. 이 나이에도 찝쩍거릴 수 있다는 사실이 놀라웠다. 올해도 어김없이 우리은행의 사주풀이를 보았다. 여전히 2022년에 남쪽에서 귀인을 만날 수 있다고 한다. 남쪽이라면... 판교인가.ㅋ 정말 마지막이다. 1년만 더 믿어봐야지.

 


 

* 계획

 

2022년 임인년(검은 호랑이해)은 피아노고 나발이고 일단 닥치고 개발. 지금처럼 꾸준히 건강하게 열심히. 하루에 딱 2시간만 고정으로 다닐 수 있는 헬스장만 있으면 좋겠는데, 일단 거주지가 확정되기 전까지는 대기. 가장 중요한... 주거지 선택에 만전을 기하기. 지금은 연봉이 얼마던 그런건 중요하지 않다. 그저 집 가진 백수의 승리. 그렇다고 해서 최고점에 물리지 않기. 서두르지 않기. 2022년 12월 31일에 기쁜 마음으로 다시 결산할 수 있기를...

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret