{
  "block": 106143960,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "7113.970093 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2026-05-18T00:40:51",
  "trx_id": "291ade1cadefe992244e382f8b2387a683cb32c5",
  "trx_in_block": 0,
  "virtual_op": 0
}

{
  "block": 105977805,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "4401.759688 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2026-05-12T05:35:21",
  "trx_id": "1b47b5839dec4b57357b27b1da28cfec56397513",
  "trx_in_block": 4,
  "virtual_op": 0
}

{
  "block": 105511600,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "7126.485849 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2026-04-26T00:01:06",
  "trx_id": "f444ecd818da9d2f1532dfba6816a9ef37977d51",
  "trx_in_block": 0,
  "virtual_op": 0
}

{
  "block": 102853185,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "4443.306507 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2026-01-23T08:56:57",
  "trx_id": "08b03f84e133f315b582f3b7da21b3d5ed5c54d5",
  "trx_in_block": 3,
  "virtual_op": 0
}

{
  "block": 91299580,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "4607.525704 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2024-12-17T04:15:30",
  "trx_id": "e3a66ced7b402e01597b8f2ee7396cb4fd45dffb",
  "trx_in_block": 0,
  "virtual_op": 0
}

{
  "block": 79853785,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "4776.659236 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2023-11-13T19:58:39",
  "trx_id": "1ca85bef9a9e5e5db04d31f707cfe407d11ee9dd",
  "trx_in_block": 4,
  "virtual_op": 0
}

{
  "block": 78348428,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "7713.938022 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2023-09-21T22:19:54",
  "trx_id": "4bf618049827cd8472f8c07d2debf7f5d9dbbc44",
  "trx_in_block": 1,
  "virtual_op": 0
}

{
  "block": 69113688,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "7935.619460 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2022-11-03T12:03:36",
  "trx_id": "0c6f26ea4a8e298cf70980eda98bda5daee682e9",
  "trx_in_block": 0,
  "virtual_op": 0
}

{
  "block": 60809823,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8156.152691 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2022-01-17T11:17:57",
  "trx_id": "c2cd2e74525ceaf5c76875b7aeef87b095b1fd92",
  "trx_in_block": 31,
  "virtual_op": 0
}

{
  "block": 54608190,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8339.921349 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2021-06-14T01:12:15",
  "trx_id": "1b399f4f6e293b987720ad069a732c004e350755",
  "trx_in_block": 8,
  "virtual_op": 0
}

{
  "block": 49355631,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8527.343323 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-12-11T11:30:21",
  "trx_id": "3f710661d4f9f77120a056c32c19916874779fea",
  "trx_in_block": 14,
  "virtual_op": 0
}

{
  "block": 49207191,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "1912.543513 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-12-06T05:07:33",
  "trx_id": "4deb64cf29baa4213ea42a2cac6f4ca5b2c6b67e",
  "trx_in_block": 0,
  "virtual_op": 0
}

{
  "block": 49190724,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8533.551177 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-12-05T15:08:27",
  "trx_id": "37072ecbf751ab9863b4daf215017c235d59a707",
  "trx_in_block": 7,
  "virtual_op": 0
}

{
  "block": 48258741,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "1920.017158 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-11-02T16:26:15",
  "trx_id": "7359ef63fc3cfd2608ee0158ca19a0738740c580",
  "trx_in_block": 3,
  "virtual_op": 0
}

{
  "block": 43217446,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8736.356536 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-05-09T06:05:18",
  "trx_id": "fa71c0c0f37fa0f2571a4bb8012a44fdb9e5f853",
  "trx_in_block": 12,
  "virtual_op": 0
}

{
  "block": 43193613,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "1953.311140 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-05-08T09:45:06",
  "trx_id": "6d55c6c814f3583eb7588b07b2ab0a9c43e09cf3",
  "trx_in_block": 13,
  "virtual_op": 0
}

{
  "block": 41257708,
  "op": [
    "comment",
    {
      "author": "steemitboard",
      "body": "Congratulations @giljae! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@giljae/birthday2.png</td><td>Happy Birthday! - You are on the Steem blockchain for 2 years!</td></tr></table>\n\n<sub>_You can view [your badges on your Steem Board](https://steemitboard.com/@giljae) and compare to others on the [Steem Ranking](https://steemitboard.com/ranking/index.php?name=giljae)_</sub>\n\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) to get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}",
      "parent_author": "giljae",
      "parent_permlink": "rest-api",
      "permlink": "steemitboard-notify-giljae-20200301t004845000z",
      "title": ""
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2020-03-01T00:48:45",
  "trx_id": "945f60b092b3e9b2a33240bc5d1ac6114801f4f0",
  "trx_in_block": 9,
  "virtual_op": 0
}

{
  "block": 35518412,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "8890.142079 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2019-08-13T14:17:54",
  "trx_id": "9c99661511e96384c504eeeae07c48423dc0eeab",
  "trx_in_block": 1,
  "virtual_op": 0
}

{
  "block": 30758562,
  "op": [
    "comment",
    {
      "author": "steemitboard",
      "body": "Congratulations @giljae! You received a personal award!\n\n<table><tr><td>https://steemitimages.com/70x70/http://steemitboard.com/@giljae/birthday1.png</td><td>Happy Birthday! - You are on the Steem blockchain for 1 year!</td></tr></table>\n\n<sub>_[Click here to view your Board](https://steemitboard.com/@giljae)_</sub>\n\n\n**Do not miss the last post from @steemitboard:**\n<table><tr><td><a href=\"https://steemit.com/carnival/@steemitboard/carnival-2019\"><img src=\"https://steemitimages.com/64x128/http://i.cubeupload.com/rltzHT.png\"></a></td><td><a href=\"https://steemit.com/carnival/@steemitboard/carnival-2019\">Carnival Challenge - Collect badge and win 5 STEEM</a></td></tr></table>\n\n###### [Vote for @Steemitboard as a witness](https://v2.steemconnect.com/sign/account-witness-vote?witness=steemitboard&approve=1) and get one more award and increased upvotes!",
      "json_metadata": "{\"image\":[\"https://steemitboard.com/img/notify.png\"]}",
      "parent_author": "giljae",
      "parent_permlink": "rest-api",
      "permlink": "steemitboard-notify-giljae-20190301t012505000z",
      "title": ""
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2019-03-01T01:25:06",
  "trx_id": "9b6857e0ba87e0a1695c22260ab685dae708bf17",
  "trx_in_block": 18,
  "virtual_op": 0
}

{
  "block": 29905530,
  "op": [
    "vote",
    {
      "author": "giljae",
      "permlink": "cmaf-common-media-application-format",
      "voter": "stoney.kang",
      "weight": 10000
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2019-01-30T09:59:33",
  "trx_id": "14c22c9dec58ba0f01a35870d736e604eb7e6d62",
  "trx_in_block": 18,
  "virtual_op": 0
}

{
  "block": 25487783,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "9088.575558 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-08-29T08:52:06",
  "trx_id": "f6a790cf32041bc779dcad6101debc45aa92d106",
  "trx_in_block": 7,
  "virtual_op": 0
}

{
  "block": 23788054,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "29420.809225 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-06-30T23:11:48",
  "trx_id": "63a5f525aa08df7cd8162aa2a46017d3ba22c5d8",
  "trx_in_block": 25,
  "virtual_op": 0
}

{
  "block": 22875580,
  "op": [
    "vote",
    {
      "author": "giljae",
      "permlink": "rest-api",
      "voter": "ax3",
      "weight": 100
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-05-30T06:05:36",
  "trx_id": "dc76a41c2e4696768c8b100f195d7ccf253ff3de",
  "trx_in_block": 42,
  "virtual_op": 0
}

{
  "block": 22875577,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "\"REST API는 일반적인 요청을 처리하는데 뛰어나며, 다수의 개발자가 API를 쉽게 사용할 수 있도록 하는 일련의 규칙을 수립합니다.\"\n위 모델에서는 모든 사람들이 규칙을 알고 있으면 엄청나게 강력해집니다. API 공급자는 일련의 규칙을 설정하고 API 소비자는 원하는 것을 얻으려면 공급자가 설정한 규칙을 준수해야 합니다.\n그러나 점점 규모가 커지고 사람들이 디지털 콘텐츠 및 서비스를 사용하는 방식이 늘어나고 있는 상황에서는 위 단일 모델 원칙이 부족할 수 있습니다.\n\nNetflix의 예를 들어 볼까요?\nNetflix는 현재 게임 콘솔, 모바일, TV, 블루레이 플레이어, Tablet, PC 및 비디오를 스트리밍 할 수 있는 거의 모든 디바이스(약 800개 이상)에서 사용할 수 있습니다.\n디바이스의 폭이 넓어지기 때문에 전체의 기능 변화를 관리하기가 어려워지는 잠재적인 문제가 발생합니다.\n\n예를 들어 Google의 REST API는 일반적인 방식으로 디바이스의 요청을 처리 할 수 있지만, 그 중 어느것도 디바이스에 맞춰서 최적화하지 않았습니다. REST API가 데이터를 세부적으로 표현하는 리소스에 초점을 맞추기 때문입니다.\n각 디바이스간의 차이점은 여러가지 경우가 존재합니다. 다음은 1:1 맞춤형 모델의 경우 지원하기 어려운 다기종 디바이스 기기간의 차이입니다.\n서로 다른 디바이스는 서로 다른 메모리 용량을 가지고 있음\n일부 디바이스는 고유하거나 독점적인 형식 혹은 전달 방법이 필요할 수 있음\n일부 디바이스는 더 Depth가 깊은 형태의 계층적 문서 모델로 성능이 향상될 수 있음\n디바이스마다 다른 화면 크기를 지니고 있기에 어떤 데이터가 필요한지에 영향을 줄 수 있음\n서로 다른 디바이스는 서로 다른 사용자 상호 작용 모델을 허용하며 메타 데이터 필드, 전달 방법, 상호 작용 모델등에 영향을 줄 수 있음\n\niPhone과 TV의 차이점과 다른 사용자 경험을 제공하는 방법과 TV에 투영되는 XBox와 Wii는 하드웨어 제약 조건과 상호 작용하는 방식이 서로 다르고 제약 조건을 지원하기 위해 서로 다른 API가 필요할 수 있습니다. 800가지가 넘는 다양한 디바이스 유형을 고려할 경우 분산해서 제공하는 방안이 압도적입니다. 그리고 더 많은 제조사가 디바이스를 계속 혁신함에 따라 편차가 커질 여지가 존재합니다.\n\n이러한 기기의 차이 때문에 Netflix UI팀은 각 기기별 사용자에게 더 나은 서비스를 제공하기 위해 REST API를 Redesign하기로 결정 합니다.\n\n위에서 언급한 것처럼 기존의 OSFA(One-size-fits-all) REST API 접근 방식에 제한 사항이 존재합니다. Netflix의 스트리밍 서비스는 800개 이상의 서로 다른 기기에서 사용할 수 있으며, 거의 모든 기기가 비공개 API로 부터 콘텐츠를 수신합니다. Netflix의 경우 OSFA API를 사용하여 다양한 기기를 지원하는 것은 성공했지만 API팀, UI팀 또는 Netflix 스트리밍 고객에게 적합하지 않음을 깨달았습니다. \n\n## 각 디바이스의 차이를 수용\n새롭게 디자인 된 API의 핵심은 800개 이상의 기기 유형에서 다양한 차이가 있다는 사실을 수용한 점입니다. Netflix가 2008년 부터 사용한 REST API를 포함한 대부분의 API는 일반적인 방식으로 기기의 요청을 처리하여 서버쪽 구현을 보다 효율적으로 만듭니다. 이 접근법에는 충분한 이유가 있는데, API 팀이 OSFA API를 제공하면 모든 사람이 따라야 하는 규칙을 설정하기 때문에 광범위한 API사용자와 확고한 관계를 유지할 수 있기 때문입니다.\n이런 규칙은 효과적이긴 하지만 OSFA의 문제점은 API 소비자가 아닌 API 제공업체가 편리하게 사용할 수 있다는 점입니다. 따라서 OSFA는 이러한 기기의 차이점을 무시합니다. \nNetflix의 새로운 모델은 OSFA 패러다임을 없애고, 각 기기의 차이점을 동등하게 지원하면서 포용하도록 설계되었습니다. 이를 위해서 API 개발 플랫폼을 통해 각 UI팀은 사용자 정의를 만들 수 있습니다. 이렇게 하므로써, Request/Response 모델은 각 팀의 UI에 맞게 최적화 될 수 있습니다.\n\n많은 OSFA 구현에서 API는 아래의 형태로 제공됩니다.\n![](https://cdn.steemitimages.com/DQmQwKgcMxJYPh4XvwAPhAbjL93MSHyfNYmqRfcFpWRQq8K/image.png)\n \n위의 그림은 Netflix 환경을 시작하기 위해 PS3에 필요한 여러 요청을 대략적으로 보여줍니다. 다른 UI는 OSFA REST API에 대해 유사한 상호 작용 세트를 갖게 됩니다. 이는 API에서 모두 동일한 규칙을 준수해야 한다는 것을 의미합니다. REST API내부에는 콘텐츠 수집, 준비 및 전달을 수행하는 엔진이 존재합니다.\n\nGoogle의 새 API는 OSFA API 모델에서 전체 API의 관리 기능을 손상시키지 않으면서 세분화 맞춤 설정이 가능하게 하는 모델로 이전 되었습니다. 다음 그림은 수정된 아키텍처를 보여줍니다.\n![](https://cdn.steemitimages.com/DQmSwZv6FZAVNZ3dvpmU6ujXwif1LCkdZ7aNYDpcQPd1ZTS/image.png)\n\n이 새로운 모델에서 UI는 사용자 요청에 대해 단일 지점을 만듭니다. 그 이후 사용자 요청에 대해 구문을 분석하고 Java API를 호출하는 처리기로 하부 API 제공 서비스를 호출합니다.\n\n## 클라이언트와 서버 사이에 Border 정의\n\"클라이언트 코드\"는 디바이스내에 있는 모든 코드를 의미합니다.\n\"서버 코드\"는 서버에 존재하는 코드로 정의됩니다.\n이 의미는 REST API의 경우에 경계를 나누는 기준이며, API 소비자와 API 제공자를 의미합니다.\n![](https://cdn.steemitimages.com/DQmf8hqAkivQ9vcGoxNGNZTxY2xTVJ5ytDwuykFKnubpRM5/image.png)\n\nNetflix의 경우 서버 코드에 많은 부분을 밀어 넣고 있습니다. 디바이스의 모든 코드는 클라이언트 코드로 간주되지만, 일부 클라이언트 코드는 서버에 위치합니다.\n클라이언트 코드는 서버에 있는 전용 클라이언트 어댑터에 요청을 하게 됩니다.어댑터는 필요없는 필드 제거, 오류 처리 및 재시도, 응답 형식, 헤더 필드등의 정보를 처리합니다. 이 모든 처리는 특정 UI에 대한 사용자 정의입니다. 아래의 그림을 확인하세요.\n![](https://cdn.steemitimages.com/DQmPJUUiYcnQKE9uepkgxpN8QEBghDuACkpbBwkoKeuYztk/image.png)\n\n위의 변화는 두 가지 측면이 있습니다.\n첫째, 네트워크를 통해 진행되는 Request를 서버에서 처리하기 때문에 디바이스와 서버간의 효율적인 상호 작용이 가능합니다. 네트워크 비용은 트랜잭션 중 가장 비싸기 때문에 네트워크 요청 수를 줄이면 성능이 향상됩니다.\n둘째, 최적화 된 어댑터를 구축해서 클라이언트 요청을 최종적으로 처리합니다. \n\n## Distributed Innovation\n이 접근 방식의 단점은 A/B 테스트 및 Multiple 테스트를 위해 더 많은 기기를 추가하고 \n더 많은 UI를 추가 할 경우 모든 개별 프로파일을 지원하는데 필요한 무수한 어댑터가 존재한다는 점입니다.\n위에서 언급한 것처럼 일부 클라이언트 코드를 서버로 보내고 API를 제공하면 UI팀이 (API팀의 개입없이) 자체 어댑터 코드를 만들고 수정할 수 있으므로 개발 과정에서 훨씬 더 민첩할 수 있습니다. 이 들은 더 이상 규칙을 지시하거나 개발을 위한 병목이 되는 서버팀에 구속되지 않습니다. API 혁신은 UI팀에게 달려있게 됩니다.\n\nUI팀이 HTML5, CSS3, JavaScript등의 기술에 더욱 숙련되어 있다는 점이 단점이긴 합니다.\n이제는 서버측 기술을 배워야 합니다. 또 다른 문제는 UI팀이 서버 측 어댑터를 구현하기 때문에 리소스 집약적인 무한 루프 또는 기타 프로세스를 통해 API 서버를 중단시킬 가능성이 존재한다는 점입니다. 이를 보완하기 위해서 Netflix의 경우 Scrubbing Engine을  개발 하고 있습니다.\n\n즉, OSFA 세계에서 장치의 코드는 서버를 쉽게 DDOS할 수 있으며, 서버에서 실행되는 경우 잠재적으로 더 큰 문제를 유발할 수 있습니다.\n\n어떻게 동작 할까요?\nPS3와 같은 기기는 네트워크를 통해 홈화면을 Load하는 단일 요청을 합니다. (이 코드는 PS3 UI팀에서 작성하고 지원)\nGroovy Adapter가 PS3 요청을 받고 구문 분석을 합니다. (PS3 UI 팀)\nAdapater는 하나의 요청을 Java API로 매핑 (PS3 UI  팀)\n각 Java API는 요청에 필요한 콘텐츠를 제공하기 위해 종속 서비스를 호출\nJava API에서 종속 서비스 사용이 불가능하거나 4xx, 5xx를 반환하면 Java API는 Adapter(API팀)에 폴백 및 오류 코드를 반환합니다.\nJava API 트랜잭션이 성공적으로 완료되면 (API팀) 콘텐츠를  Adapter로 반환 합니다.\nAdapter가 콘텐츠를 조작하고, 원하는 요소를 가져오거나 잘라내고 오류를 처리 (PS3 UI 팀)\nAdapter는 PS3 홈 화면에 필요한 모든것을 포함하여 응답 형식을 지정합니다. (PS3 UI 팀)\n클라이언트에게 Payload를 전달합니다. (PS3 UI 팀)\n클라이언트가 구문을 분석하고 UI를 표현합니다. (PS3 UI 팀)\n\n이 새로운 모델은 아직 초기 단계에 있으며, REST API를 사용하는 기기와 새로운 모델을 사용하는 기기로 현재 혼재되어 있습니다.\n\nSource: https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d",
      "json_metadata": "{\"tags\":[\"kr\",\"netflix\",\"dev\"],\"image\":[\"https://cdn.steemitimages.com/DQmQwKgcMxJYPh4XvwAPhAbjL93MSHyfNYmqRfcFpWRQq8K/image.png\",\"https://cdn.steemitimages.com/DQmSwZv6FZAVNZ3dvpmU6ujXwif1LCkdZ7aNYDpcQPd1ZTS/image.png\",\"https://cdn.steemitimages.com/DQmf8hqAkivQ9vcGoxNGNZTxY2xTVJ5ytDwuykFKnubpRM5/image.png\",\"https://cdn.steemitimages.com/DQmPJUUiYcnQKE9uepkgxpN8QEBghDuACkpbBwkoKeuYztk/image.png\"],\"links\":[\"https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "rest-api",
      "title": "다양한 장치를 지원하는 REST API에 대해 고찰"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-05-30T06:05:27",
  "trx_id": "859f7cacc4eed08abc56543191f15cc920d88561",
  "trx_in_block": 15,
  "virtual_op": 0
}

{
  "block": 21322385,
  "op": [
    "vote",
    {
      "author": "giljae",
      "permlink": "netflix-open-connect",
      "voter": "mircokim22",
      "weight": 10000
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-04-06T06:41:45",
  "trx_id": "3adfb291314f1cd3404a7a1405e14e404a87c3de",
  "trx_in_block": 20,
  "virtual_op": 0
}

{
  "block": 21322359,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "Netflix의 Open Connect 콘텐츠 딜리버리팀은 콘텐츠의 인기도를 예측하여 인프라 효율을 극대화 하려고 합니다.\nContent Delivery관점에서는 시청 횟수로 인기 콘텐츠를 판별합니다. 즉, 스트리밍된 총 바이트 수를 Asset의 크기(byte)로 나누어 계산합니다.\n\n그럼, 콘텐츠와 CDN 최적화는 어떤 관계가 있을까요?\n일반적으로 CDN에서는 짧은 네트워킹 경로를 통해 최대한 많은 콘텐츠를 제공하려고 합니다. 네트워크 대기시간을 줄임으로써 사용자들의 스트리밍 환경을 극대화 할 수 있기 때문입니다.\n\n![](https://steemitimages.com/DQmTjvmZWBDh6FBaEuMKqhj92vovTbXWAPMSJrneAbFhKZw/image.png)\n\n서버당 사용할 수 있는 디스크 공간이 제한되어 있으므로 모든 Edge Server에 모든 콘텐츠를 넣을 수가 없습니다.\n따라서 가장 많이 사용되는 콘텐츠만 Cache하게 됩니다.\n\nNetflix의 경우 많은 트래픽을 발생시키는 Edge에서 계층화된 인프라를 사용합니다. 100G를 처리하는 서버는 매우 인기있는 콘텐츠를 제공하는데 사용되고 대용량 스토리지(200TB+)는 Warm/Cold 콘텐츠를 제공하는데 사용됩니다.\n이러한 계층 구조를 적절하게 구성하기 위해 인기도에 따라 콘텐츠의 순위를 관리할 필요가 있습니다.\n\n매우 인기 있는 콘텐츠가 단일 서버에만 배포되는 경우 해당 서버의 최대 리소스를 사용할 수 있지만 다른 서버는 활용되지 못할 수 도 있습니다.\n\n 1) 인기있는 파일은 디스크에서 읽어오는 것이 아니라 메모리에 위치해 있습니다. 메모리 최적화는 디스크 I/O가 병목현상의 원인이 될 가능성을 제거 합니다.\n 2) Netflix는 네트워크의 근접성을 기반으로 트래픽을 라우팅하기 떄문에 가장 인기 있는 콘텐츠도 Edge 네트워크에서 공유되고 확산됩니다.\n\n따라서, 콘텐츠의 복사본을 보관합니다.\nConsistent Hashing은 클러스터내의 여러 서버에 콘텐츠를 할당하는데 사용됩니다.\n일반적으로 해싱은 균형잡힌 클러스터를 생성하지만 모든 파일이 지정된 위치의 단일 서버에서 제공되는 경우 트래픽 분산에 문제가 생길 수 있습니다.\n\n예를 들어서, 큰 바위더미들에게서 여러 곳으로 배포하려고 하면 무게가 모두 같지 않을 수 있는 가능성이 커집니다.\n그러나 자갈더미와 같이 작은 돌멩이만 있다면 더 높은 확률로 가중치의 균형을 맞출 수 있습니다.\n즉, 인기가 높은 콘텐츠(큰 암석)은 여러 복사본으로 배포하여 덜 인기 있는 콘텐츠(조약돌)로 분류 할 수 있습니다.\n\n![](https://steemitimages.com/DQmWMoNpip7wWXv5vCKpaHQwJc9JbsmFzWwRKacnYfARASn/image.png)\n\n트래픽이 증가하면 각 서버는 전체 트래픽 수준에서 최고 사용률에 도달하도록 서버를 균등하고 균형있게 유지할 수 있습니다. 이를 통해 전체 클러스터에서 처리되는 트래픽양을 최대화 할 수 있습니다.\n\n스마트TV, iOS에서 사용되는 프로필은 서로 다른 수준의 품질로 인코딩됩니다. 그리고 오디오 프로필과 자막을 여러 언어로 제공하기에 콘텐츠, 인코딩 프로필, 비트 전송률, 언어 기준으로 하나 이상의 파일을 Cache해야 합니다. 예를 들어 The Crown의 한 에피소드를 스트리밍하려면 1200개의 파일을 저장합니다.\n\n![](https://steemitimages.com/DQmYjrN6j8ee95d4FhdNaZ1U7PdK6XQjPmZq5VJ621o4SYV/image.png)\n\nNetflix의 경우 과거의 시청 패턴을 기반으로 미래의 시청 패턴을 예측합니다. 이를 수행하기 위한 가장 간단한 방법은 특정 날짜에 시청한 콘텐츠 회원을 보고 내일 동일한 콘텐츠를 볼 것이라 가정하는 것입니다. 그러나 현실은 쉽지 않습니다. 여러가지 변수가 존재하기에 콘텐츠 인기도는 변동될 수 있으며 이는 콘텐츠를 잘못 지정하는 사태가 발생할 수 있습니다.\n콘텐츠 인기를 계산하는 모델은 여러가지가 존재합니다.\n\n콘텐츠 타이틀 기준: 콘텐츠 타이틀과 관련된 모든 파일이 단일 그룹으로 순위가 지정 됩니다. 이는 단일 스트리밍 세션관 관련된 모든 파일(비디오, 오디오등 다중 프로필)이 단일 서버에 있음을 의미합니다. 이것의 단점은 인기 없는 프로필의 경우도 타이틀 기준이기에 저장해야 한다는 것입니다.\n파일 기준: 모든 파일에 대해 인기도가 결정됨, 이 방법을 적용하면 같은 타이틀내에 존재하는 프로필 파일의 순위가 달라집니다. (인기있는 타이틀이라도 저화질은 안볼수 있기에...) 이 매커니즘은 Cache의 효율성을 크게 향상시킵니다.\nNetflix의 경우 2016년도에 타이틀 기준에서 파일 기준으로 마이그레이션을 진행했고, 50% 수준의 스토리지 용량으로 동일한 Cache 효율성을 달성 했다고 합니다.\n\n그럼, 새롭게 추가되는 콘텐츠 타이틀에 대해서는 어떻게 해야 하는것이냐?\nNetflix의 경우 처음 출시되는 콘텐츠에 대해서 내부 및 외부 예측을 통해 인기도를 예측합니다. 물론, 이 부분의 정확하지 않기에 유기적인 예측으로 이를 정상화합니다.\n\nSources:\nhttps://medium.com/netflix-techblog/content-popularity-for-open-connect-b86d56f613b",
      "json_metadata": "{\"tags\":[\"kr\",\"cdn\",\"netflix\",\"cache\",\"media\"],\"image\":[\"https://steemitimages.com/DQmTjvmZWBDh6FBaEuMKqhj92vovTbXWAPMSJrneAbFhKZw/image.png\",\"https://steemitimages.com/DQmWMoNpip7wWXv5vCKpaHQwJc9JbsmFzWwRKacnYfARASn/image.png\",\"https://steemitimages.com/DQmYjrN6j8ee95d4FhdNaZ1U7PdK6XQjPmZq5VJ621o4SYV/image.png\"],\"links\":[\"https://medium.com/netflix-techblog/content-popularity-for-open-connect-b86d56f613b\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "netflix-open-connect",
      "title": "Netflix Open Connect에서 인기 콘텐츠 관리 방법"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-04-06T06:40:27",
  "trx_id": "b101b9dd9b2a565e5c0530a8a84aa5f19e9dfab0",
  "trx_in_block": 8,
  "virtual_op": 0
}

{
  "block": 20815539,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"postresteem\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:36",
  "trx_id": "846e5fd602a505d9ab2c0ffaf54efa09de686d74",
  "trx_in_block": 5,
  "virtual_op": 0
}

{
  "block": 20815538,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"palui\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:33",
  "trx_id": "569fe84a02011c508c1ba3e93e7876be6b78be36",
  "trx_in_block": 60,
  "virtual_op": 0
}

{
  "block": 20815537,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"mulyaabadi\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:30",
  "trx_id": "9e740fa48bc0793e59ee9257fa163a51432858b4",
  "trx_in_block": 38,
  "virtual_op": 0
}

{
  "block": 20815536,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"cryptoasis\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:27",
  "trx_id": "83afd85ae62a7b447972ee3b9b620d71740a0f11",
  "trx_in_block": 31,
  "virtual_op": 0
}

{
  "block": 20815536,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"cryptonnn\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:27",
  "trx_id": "cb8df9023281de81900f2b7ad20a03ca1f9311fc",
  "trx_in_block": 29,
  "virtual_op": 0
}

{
  "block": 20815535,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"biwi3\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:24",
  "trx_id": "101464be62f62bd3d9e2603867af76fbb6f2accd",
  "trx_in_block": 51,
  "virtual_op": 0
}

{
  "block": 20815535,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"abawhale\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-19T15:32:24",
  "trx_id": "2087468f41517ac2313a9927f3d9f57aee6895c1",
  "trx_in_block": 32,
  "virtual_op": 0
}

{
  "block": 20699832,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"otobot\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-15T15:05:18",
  "trx_id": "dcc2db8b1129c5830396706ea4849e925187e232",
  "trx_in_block": 18,
  "virtual_op": 0
}

{
  "block": 20640629,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"mcgrafite\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-13T13:40:12",
  "trx_id": "4cf28363e32544f4d1798b837d18c95df9995d64",
  "trx_in_block": 11,
  "virtual_op": 0
}

{
  "block": 20640628,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"halloworld\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-13T13:40:09",
  "trx_id": "1bf41785d694c3de9968de5830e7efd9192ba544",
  "trx_in_block": 47,
  "virtual_op": 0
}

{
  "block": 20596927,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"imagediet\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-12T01:13:21",
  "trx_id": "473f17f210ff95a6b9e6ddbcfe58d5ec7338ab8d",
  "trx_in_block": 8,
  "virtual_op": 0
}

{
  "block": 20580828,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"scientificmemo\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-11T11:46:57",
  "trx_id": "d022131710e9d9dab0344f2438bdf5e5accb3a7a",
  "trx_in_block": 55,
  "virtual_op": 0
}

{
  "block": 20580827,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"pillsjee\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-11T11:46:54",
  "trx_id": "ae19f186d47b4f4ef3fa8d02e95f6e65faed2863",
  "trx_in_block": 37,
  "virtual_op": 0
}

{
  "block": 20580827,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"forall\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-11T11:46:54",
  "trx_id": "a07cf4efb28313c45a6e778b81bb8b05745cb405",
  "trx_in_block": 7,
  "virtual_op": 0
}

{
  "block": 20580826,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"bigshot\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-11T11:46:51",
  "trx_id": "8d224c999ba655a7a04ad70dacc12fbec6fd56cc",
  "trx_in_block": 55,
  "virtual_op": 0
}

{
  "block": 20551766,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"einsundnull\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-10T11:30:33",
  "trx_id": "06bdc9b76cc6e958d82041861c932a7637ae9e6e",
  "trx_in_block": 1,
  "virtual_op": 0
}

{
  "block": 20551764,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"bustillo\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-10T11:30:27",
  "trx_id": "e5d13630850126ba9e698177efd34b9aa420ea65",
  "trx_in_block": 52,
  "virtual_op": 0
}

{
  "block": 20551764,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"bestboom\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-10T11:30:27",
  "trx_id": "45c3386da175875f3bec268d6e42f025cfff25a5",
  "trx_in_block": 44,
  "virtual_op": 0
}

{
  "block": 20528077,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"ctf\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-09T15:43:00",
  "trx_id": "e2cf68c9d55931205ad7a342f9562ba49bfa299d",
  "trx_in_block": 8,
  "virtual_op": 0
}

{
  "block": 20528073,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"bilal-haider\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-09T15:42:48",
  "trx_id": "160fdea8aae63cc7a3422c02c99137378819a6e9",
  "trx_in_block": 32,
  "virtual_op": 0
}

{
  "block": 20499379,
  "op": [
    "claim_reward_balance",
    {
      "account": "giljae",
      "reward_sbd": "0.013 SBD",
      "reward_steem": "0.000 STEEM",
      "reward_vests": "8.169175 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:47:57",
  "trx_id": "015eb7f9e3a609c7db538c5663312589df22bd48",
  "trx_in_block": 31,
  "virtual_op": 0
}

{
  "block": 20499200,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "HashiCorp에서 제공하는 Consul은 Service Discovery, Failure Detection, Multi Datacenter, KV Storage 기능을 제공합니다.\n\nHAproxy 혹은 Nginx와 같은 Software 기반의 Load Balancer를 Cloud 상에 구축한다고 가정해보면, 고려해야 할 사항은 아래와 같습니다.\n\n* 부하량에 따라 LB가 Scale In/Out이 되어야 한다.\n* 로드 밸런싱 대상이 되는 Backend 서비스가 Scale In/Out이 되면 LB의 Configuration이 실시간으로 변경되어야 하며, 각 LB에게 동기화가 되어야 한다.\n* LB의 Health check가 수행되어야 한다.\n\n이 정도로만 간추려봐도 LB하나를 도입하기 위해 해야할 일이 많아지게 됩니다. 분산 환경에서의 이러한 일을 처리하기 위해 예전에는 Apache Zookeeper를 이용하여 개발을 했었지만 이번에는 Consul을 이용해보기로 했습니다.\n\nApache Zookeeper와 HashiCorp의 Consul의 차이점은 아래와 같습니다.\n\n**Apache Zookeeper**\n* Written in Java\n* Strongly consistent (CP)\n* Zab protocol (Paxos like)\n* Ensemble of servers\n* Quorum needed (majority)\n* Dataset must fit in memory \n\nZookeeper는 현재 많은 곳에서 활용되고 있지만, 몇가지 문제점을 지니고 있습니다.\n\n**Zookeeper : Problems**\n* Latency-dependent\n* No multi datacenters support (very slow write)\n* Client number limit (out of sockets)\n* Designed to store data on the order of KB in size\n* Possibly lost changes while reenabling watch\n* TCP connection != service healthy (proxy)\n* Change zk server is a problem\n\n이러한 문제점들을 보완해서 나온 제품이 Consul입니다. Consul의 특징을 보시죠.\n\n**HashiCorp Consul**\n* Written in Go\n* Service discovery\n* Health checking\n* Key / Value Store\n* Multi datacenter support\n* Agent / Server Concept\n* Gossip protocol for all the nodes (discovery)\n* Consensus protocol (Raft-based) for servers\n* 3 consistency modes\n* Access Control List (ACL)\n\nConsul에서 제공하는 기능을 HAProxy에 적용을 해봤고 결과는 만족스럽습니다.\n\nHAProxy는 GSLB or DNS RR로 상위 Client에서 접속을 시도하게 되게되고 이 경우 HAProxy를 HA구성(Active-Standby)을 해야 합니다.\n\nHAProxy가 설치된 VM에 consul agent를 등록하고 별도의 config 파일을 만들어 HAProxy에 대해서 Health checking을 수행 합니다. LB 매커니즘이 Round Robin일 경우 HTTP로 health check를 하게되면 LB가 문제가 될 소지가 많기에, 저의 경우에는 별도의 script를 만들어서 health checking을 수행했습니다.\n\nhaproxy.cfg 파일을 중앙에서 관리하기 위해 haproxy.cfg.ctmpl 파일을 만들어 consul-template daemon을 구동합니다. haproxy.cfg.ctmpl내에 별도의 key를 만들어 이 정보를 Consul의 K/V store에서 관리 및 변경시 모든 node에 즉시 동기화가 됩니다.\n\n이렇게 함으로써 HAProxy를 도입할때의 고려사항 중 일부가 해소가 되었습니다.\n앞으로 남은 부분은 consul-ui에서 확인할 수 있는 alarm 및 기타 정보를 push 형태로 IaaS Management 쪽에 전달하는 부분만 보완하면 될 것 같습니다. consul-ui는 어디까지나 확인 용도이고 IaaS management tool과 Integration이 되어야 하기 때문입니다.\n\n그동안 Zookeeper를 쓰면서 client number limit, TCP connection, store data design 부분에 대해서 고민이 있었는데, consul을 활용하면서 이런 부분이 어느정도 해소가 될 것으로 보여집니다.\n\n관련하여 좋은 Tip이 있으면 같이 공유했으면 합니다.",
      "json_metadata": "{\"tags\":[\"kr\",\"zookeeper\",\"consul\",\"hashicorp\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "hashicorp-consul-consul-template",
      "title": "HashiCorp사의 Consul, Consul Template 소개"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:39:00",
  "trx_id": "6bff48e0284042c0f6473538db4cd6348cb84611",
  "trx_in_block": 21,
  "virtual_op": 0
}

{
  "block": 20499096,
  "op": [
    "comment",
    {
      "author": "cheetah",
      "body": "Hi! I am a robot. I just upvoted you! I found similar content that readers might be interested in:\nhttp://www.giljae.com/2017/09/",
      "json_metadata": "",
      "parent_author": "giljae",
      "parent_permlink": "netflix-netflix-and-fill",
      "permlink": "cheetah-re-giljaenetflix-netflix-and-fill",
      "title": ""
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:33:48",
  "trx_id": "9836e4e00f3dc5285c9aa5a310918dfd0c15ca35",
  "trx_in_block": 50,
  "virtual_op": 0
}

{
  "block": 20499095,
  "op": [
    "vote",
    {
      "author": "giljae",
      "permlink": "netflix-netflix-and-fill",
      "voter": "cheetah",
      "weight": 8
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:33:45",
  "trx_id": "d2bcd9424159c447fbb2c9fd43be8b7af5e31a70",
  "trx_in_block": 21,
  "virtual_op": 0
}

{
  "block": 20499092,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "본 글은 넷플릭스의 Tech블로그의 내용과 개인적인 의견을 포함하여 작성했습니다.\n(참조: https://medium.com/netflix-techblog/netflix-and-fill-c43a32b490c0)\n\n새로운 콘텐츠가 출시 되면 CP(Content Provider)로부터 넷플릭스내의 콘텐츠 운영팀으로 Digital Asset이 전달 됩니다.\n이 과정에서 Netflix Platform에 통합하기 위해 필수적인 품질관리, 인코딩등 다양한 유형의 처리 및 개선이 이루어집니다. 이 단계가 끝나면 관련 Digital Asset (Bitrate, Caption)이 다시 패키징되어 Amazon S3에 배포 됩니다.\n배포 준비가 된 S3의 콘텐츠는 콘텐츠 운영팀에 의해 metadata flag가 지정되며, 이 시점에서 Open Connect 시스템이 인계받아 OCA(Open Connect Appliance)에 콘텐츠를 배포하기 시작합니다.\n\n# Proactive Caching\nNetflix의 Open Connect와 다른 CDN과의 가장 큰 차이점은 Proactive Caching입니다. 사용자들이 시청할 시간과 시청 시간을 높은 정확성으로 예측할 수 있기 때문에 구성 가능한 시간대 동안 non-peak bandwidth를 사용하여 예측한 콘텐츠를 OCA에 다운로드 할 수 있습니다. 다른 CDN은 이것이 불가능하고 범용적인 Delivery Service를 제공해야 하므로, LRU기반의 Caching을 선호하지요. CDN 사업자가 콘텐츠를 예측할 필요는 없으니까요. 그들은 미디어 사업자가 아니니까요.\n\n# OCA Clusters\nNetflix의 Fill pattern이 어떻게 동작하는지 이해하려면 OCA가 IX에 위치하거나 ISP 네트워크에 포함되어 있는지 여부에 상관없이 OCA 클러스터를 구성하는 방법을 이해해야 합니다.\n\nOCA는 manifest cluster로 그룹화 됩니다. 각 manifest 클러스터는 적절한 콘텐츠 영역(콘텐츠를 스트리밍 할 것으로 예상되는 국가 그룹), 인기도 피드(이전 데이터를 기준으로 간략하게 정렬된 콘텐츠 목록)로 구성되고 보유해야 하는 콘텐츠의 수를 표시합니다. Netflix는 국가, 지역 또는 기타 선정 기준에 따라 독립적으로 인기 순위를 계산합니다.\n\nFill cluster는 shared content영역과 인기 피드가 있는 manifest cluster의 그룹입니다. 각각의 fill cluster는 Open Connect 운영팀에 의해 fill escalation policies와 fill master의 수로 구성됩니다.\n\n아래의 다이어그램은 동일한 Fill cluster내의 manifest cluster의 예를 설명합니다.\n![](https://steemitimages.com/DQmSJuoCDmybLLNkLVUbPktKtphWeL8YDY1j6nuiM4hPpEL/image.png)\n\n# Fill Source Manifests\nOCA들은 네트워크내의 다른 OCA에 대한 정보, 콘텐츠, 인기도등을 저장하지 않습니다. 모든 정보는 AWS Control Plain에 집계되고 저장 됩니다. OCA는 주기적으로 Control Plain과 통신하여 Cluster 멤버들에게 storing하고 serving해야 할 콘텐츠 목록이 포함된 manifest 파일을 요청합니다. AWS Control Plain은 여러 고수준 요소를 고려하여 ranked list를 다운로드 할 수 있는 location을 response합니다.\n* Title(Content) availability - Does the fill source have the requested title(content) stored?\n* Fill health - Can the fill source take on additional fill traffic?\n* A calculated route cost - Described in the next section. (아래 섹션에서 설명)\n\n# Calculating the Least Expensive Fill Source\nS3(Origin)에서 모든 OCA에 직접 콘텐츠를 배포하는 것은 시간과 비용면에서 비효율적이므로 계층화된 접근법을 사용 합니다. Open Connect의 목표는 가장 효율적인 경로를 사용하여 콘텐츠를 전달하도록 하는 것입니다.\nLeast expensive fill source를 계산하기 위하여 각 OCA의 네트워크 상태 및 구성 매개변수를 고려합니다.\n* BGP path attributes and physical location (latitude / longitude)\n* Fill master (number per fill cluster)\n* Fill escalation policies\n\nFill escalation policies는 다음과 같이 정의합니다.\n1. OCA가 콘텐츠를 다운로드 하기 위해 갈 수 있는 hop 수와 대기시간\n2. OCA가 정의된 hop 이상으로 전체 Open Connect 네트워크로 이동 할 수 있는지 여부와 대기시간\n3. OCA가 S3(Origin)으로 갈 수 있는 여부와 대기시간\n\nControl Plain은 Master로 지정된 OCA를 선택합니다. Master에 적용되는 fill escalation policies는 일반적으로 콘텐츠를 가져와서 non-master와 로컬로 공유하기 위한 지연시간을 줄여 최대한 멀리 도달 할 수 있게 합니다.\n경로 계산에 대한 모든 입력이 주어지면, fill source 작업은 다음과 같이 작동합니다.\n1. Peer fill - Available OCAs within the same manifest cluster or the same subnet\n2. Tier fill - Available OCAs outside the manifest cluster configuration\n3. Cache fill - Direct download from S3\n\n# Example Scenario\nFill master OCA가 S3로 부터 콘텐츠 다운로드를 완료 한 후 Control Plain에 콘텐츠가 저장되었음을 보고 합니다.\n![](https://steemitimages.com/DQmYboQVPfqaUwbgRSBeR4UUhijEiTu5jpRQdVRP4vdWUab/image.png)\n\n그 다음 다른 OCA가 Control Plain과 통신하여 해당 콘텐츠의 fill source 요청을 보내면 Fill master에서 fill option이 제공됩니다.\n![](https://steemitimages.com/DQmQS9G5o3d1pJhFLjiYGPJRxNQzVArVW5rKhhUCfExjmaH/image.png)\n\n두 번째 계층의 OCA가 다운로드를 완료하면 상태를 보고하고 다른 OCA는 해당 콘텐츠에 대한 fill source 작업을 수행 합니다. 이 작업은 fill window내에서 계속 반복됩니다.\n더 이상 필요없는 콘텐츠는 delete manifest에 저장되고 일정 기간 후에 삭제됩니다.\n\nNetflix 사용자가 스트리밍을 시작하면 이 시간대의 fill source 작업이 끝나고, fill window가 다른 시간대로 이동하면서 fill source pattern이 계속 진행 됩니다. (Netflix는 글로벌 서비스이기에 각 지역별로 네트워크 유휴 시간대가 다름)\n\n# Challenges\nNetflix는 항상 fill process를 개선하고 있습니다. Open Connect 운영팀에서는 내부 툴을 사용하여 Fill traffic을 지속적으로 모니터링합니다. member들에게 서비스를 제공해야하는 catalog의 임계값 비율을 포함하지 않는 OCA에 대한 alert이 설정되고 모니터링 됩니다. 이 경우에는 다음 Fill process 전에 해당 문제를 해결합니다. 신속하게 배포해야 하는 새로운 콘텐츠나 기타 수정 사항에 대해 주기적으로 fast-track fill을 수행 할 수 있습니다. 기본적으로 이러한 fill pattern을 사용하면서 배포 시간 및 프로세싱 시간을 줄입니다.\n\nNetflix는 190개국에서 운영되고 있으며 전 세계 여러 ISP 네트워크에 수천 개의 장비가 내장되어 있기에 ISP에 대한 대역폭 비용을 최소화 하면서 OCA에 최신 콘텐츠를 빨리 얻을 수 있도록 하는데에 집중하고 있습니다.\n\n# 끝으로\nNetflix가 일반적인 Caching(LRU, NRU)방식이 아닌 Proactive caching 방식을 택한 이유는 그들이 가지고 있는 Network를 온전히 서비스를 위해서 사용하기 위함으로 보여진다. \nNRU, LRU는 Proactive caching에 비해 Miss가 발생할 확률이 존재하기에 이러한 대역폭도 서비스적인 측면에서는 아깝다는 그들의 집착이 보여진다. \n\nNetflix는 일반 CDN업체가 아닌 미디어 사업자이기에 가능한 얘기가 아닐까? \n결국 그들의 생각은 OCP는 비교적 저렴한 x86기반의 하드웨어를 쓰고 네트워크를 최대한 활용하여 가성비 있는 Open Connect를 운영하고 그 남는 비용으로 콘텐츠를 제작하겠다 아닐까?\n\n관련된 내용은 아래의 동영상과 링크를 참조\nhttps://www.youtube.com/watch?v=KtSBbsSwq-g\n\nhttps://johannesbergsummit.com/wp-content/uploads/sites/6/2014/11/Monday_8_David-Fullagar.pdf",
      "json_metadata": "{\"tags\":[\"kr\",\"netflix\",\"openconnect\",\"caching\",\"cdn\"],\"image\":[\"https://steemitimages.com/DQmSJuoCDmybLLNkLVUbPktKtphWeL8YDY1j6nuiM4hPpEL/image.png\",\"https://steemitimages.com/DQmYboQVPfqaUwbgRSBeR4UUhijEiTu5jpRQdVRP4vdWUab/image.png\",\"https://steemitimages.com/DQmQS9G5o3d1pJhFLjiYGPJRxNQzVArVW5rKhhUCfExjmaH/image.png\",\"https://img.youtube.com/vi/KtSBbsSwq-g/0.jpg\"],\"links\":[\"https://medium.com/netflix-techblog/netflix-and-fill-c43a32b490c0\",\"https://www.youtube.com/watch?v=KtSBbsSwq-g\",\"https://johannesbergsummit.com/wp-content/uploads/sites/6/2014/11/Monday_8_David-Fullagar.pdf\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "netflix-netflix-and-fill",
      "title": "Netflix, 그들의 콘텐츠 서비스 방식 (Netflix and Fill)"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:33:36",
  "trx_id": "25bf46d2815f64491d75eea7b356e9d923b79955",
  "trx_in_block": 5,
  "virtual_op": 0
}

{
  "block": 20498958,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "2012년에 나왔던 자료인거 같은데…\n이전에 작성한 \"Netflix, 그들의 콘텐츠 서비스 방식(Netflix and Fill)\" 과 연관이 있어 보인다.\n\n![](https://steemitimages.com/DQmd3AeAEdEaBFFeRneCiS4a7UAXs6UHk4ksFVQP35fw18M/image.png)\nVOD를 처음 시작할때는 Caching이 필요하지 않았다. VOD가 초기 단계에 있었을 때 하나의 중앙 서버가 전체 노드를 지원했었고 콘텐츠는 SD 포맷으로만 제공 되었다. 한곳에서 콘텐츠를 관리했기에 Caching이 필요하지 않았다.\n\n![](https://steemitimages.com/DQmR5AtJX7Z4u2jjRmRTbT7cwAkE1ncDi6RFaM7dkWcdVHP/image.png)\nVOD가 많아짐에 따라 Caching이 필요하게 되었다. LRU는 지능형 Caching으로 진화했다.\n\n![](https://steemitimages.com/DQmUGbhMFYCiGbwmSpJnD6nbG7z2CEXD8C5UceFTUQioX7V/image.png)\nCaching은 미래 행위를 예측하기 위해 과거 행위를 이용하려는 예측 활동이다. Caching은 삭제해야 할 콘텐츠를 결정하는 것이 중요하다. LRU는 사용 패턴에 관계없이 가장 오래동안 사용하지 않은 콘텐츠를 제거한다.\nIntelligent Caching은 전체 시청 시간을 기반으로 추가 조회 가능성에 대한 통계적 추론 기법을 가미한다.\n\n![](https://steemitimages.com/DQmVxcFCTXHFQFFrFzuBMa998gTqUDx4yCZ18ohLxn7V3GT/image.png)\n이 장표를 소개할 시점의 CDN Caching 알고리즘의 주류는 LRU\n\n![](https://steemitimages.com/DQmU7HZY6dBqoBGSPGcXgBXoNWRKCAUd1yXjFvwcsWsYAQB/image.png)\n예측 가능성을 향상 시키기 위해서는 동일한 콘텐츠에 대한 모든 스트림 요청이 동일한 edge streamer로 전달되어야 하며, Cluster Manager를 사용하여 콘텐츠 요청 경로를 지정해야 한다. Netflix의 경우 Control Plain으로 보면 될듯\n\n![](https://steemitimages.com/DQmfUi3Yk39wtg1Xjxk2msEmm4kc1LfLYKfSLYFYT4FYNRU/image.png)\n동일한 Cache에서 같은 콘텐츠를 스트리밍하면 count가 증가하고 네트워크 사용률이 감소한다. 이렇게 되려면 Cluster Manager가 Edge를 Referring 해야 한다.\n\n![](https://steemitimages.com/DQmcWWUAvPZaFC2W6FiN48Wp2Fdde62vjwG46bjnTYBqs1C/image.png)\nLRU caching은 콘텐츠 및 콘텐츠 위치, usage에 대한 정보가 없다. 즉, 가장 최근에 사용된 콘텐츠를 결정하고 나머지는 제거한다.\nIntelligent caching은 Edge에 콘텐츠를 잘 갖다 놓고 여러 매개 변수를 사용하여 Edge에 저장된 Chunk의 실제 가치를 평가하기에 보다 효율적으로 동작한다.\n\n![](https://steemitimages.com/DQmYF58n6cTPk643aEK8AUfoUogAYyiQVD7Nrx6d3CaMj7G/image.png)\nCaching은 패키징 옵션의 영향을 받는다는 의미인데, 어떤 방식으로 패키징하고 Origin에 어떤 모양으로 담겨 있는지에 따라 Caching에 영향을 준다는 의미인듯...\n\nSource: https://www.slideshare.net/briantarbox/2012-ncta-motorolaintelligent-caching-and-packaging-in-an-abr-multiformat-cdn-tarboxfinal",
      "json_metadata": "{\"tags\":[\"kr\",\"cdn\",\"cache\",\"media\",\"netflix\"],\"image\":[\"https://steemitimages.com/DQmd3AeAEdEaBFFeRneCiS4a7UAXs6UHk4ksFVQP35fw18M/image.png\",\"https://steemitimages.com/DQmR5AtJX7Z4u2jjRmRTbT7cwAkE1ncDi6RFaM7dkWcdVHP/image.png\",\"https://steemitimages.com/DQmUGbhMFYCiGbwmSpJnD6nbG7z2CEXD8C5UceFTUQioX7V/image.png\",\"https://steemitimages.com/DQmVxcFCTXHFQFFrFzuBMa998gTqUDx4yCZ18ohLxn7V3GT/image.png\",\"https://steemitimages.com/DQmU7HZY6dBqoBGSPGcXgBXoNWRKCAUd1yXjFvwcsWsYAQB/image.png\",\"https://steemitimages.com/DQmfUi3Yk39wtg1Xjxk2msEmm4kc1LfLYKfSLYFYT4FYNRU/image.png\",\"https://steemitimages.com/DQmcWWUAvPZaFC2W6FiN48Wp2Fdde62vjwG46bjnTYBqs1C/image.png\",\"https://steemitimages.com/DQmYF58n6cTPk643aEK8AUfoUogAYyiQVD7Nrx6d3CaMj7G/image.png\"],\"links\":[\"https://www.slideshare.net/briantarbox/2012-ncta-motorolaintelligent-caching-and-packaging-in-an-abr-multiformat-cdn-tarboxfinal\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "intelligent-caching-and-packaging-in-an-abr-multi-format-cdn",
      "title": "Intelligent Caching and Packaging in an ABR Multi-format CDN"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:26:51",
  "trx_id": "e2fa8fda76cc30aa6fe26e90bc98b60d876e86c2",
  "trx_in_block": 44,
  "virtual_op": 0
}

{
  "block": 20498887,
  "op": [
    "account_update",
    {
      "account": "giljae",
      "json_metadata": "{\"profile\":{\"name\":\"Giljae Joo (주길재)\",\"profile_image\":\"https://pbs.twimg.com/profile_images/954704293499584512/RrM8DYi7_400x400.jpg\",\"location\":\"Seoul\",\"website\":\"http://giljae.com\",\"about\":\"Slow Slow (Run Run) 내일을 사랑하오!\"}}",
      "memo_key": "STM8e6bwhYpucmTDV49uyY4CKYAe6zDebwwY83uuF8zzDJhgPhKnW"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:23:18",
  "trx_id": "7df98fd6d8d3a5d0e8852b29825d550315e65ddc",
  "trx_in_block": 5,
  "virtual_op": 0
}

{
  "block": 20498844,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "CMAF는 비디오 스트림을 여러 장치에서 저렴하고 쉽게 전달할 수 있도록 Microsoft 및 Apple에서 MPEG 형식으로 정의한 표준화 된 새로운 미디어 스트리밍 형식입니다.\n\n오늘날 거의 모든 스트리밍 비디오가 표준화 된 인코딩 기술을 사용하여 압축되지만 “비디오의 경우 H.264 또는 H.265(HEVC)이고 오디오의 경우 AAC로 압축하고 있습니다.”\nContainer는 이러한 파일에 Timing 정보를 추가하고 기타 meta data를 추가할 수 있습니다. 그리고 이러한 Container는 표준화 되지 않았습니다.\n\nApple의 HTTP Live Streaming(HLS) 프로토콜은 데이터를 MPEG-2 TS로 래핑하거나 캡슐화합니다. MPEG-DASH는 MPEG-4 Container(ISOBMFF)를 사용합니다.\n결국, 재생할 실제 미디어는 동일한 포맷으로 되어 있지만 이런 캡슐화 포맷을 사용하면 다른 포맷을 만들어야 합니다.\n\nOTT 서비스 제공 업체들은 비디오를 스트리밍 하기전에 이 작업을 수행해야 합니다. 그리고 이런 작업을 통해 생성된 파일을 저장해야 합니다.\n즉, 사용자에게 HLS, DASH 서비스를 제공하기 위해 추가 비용이 발생하며, 이런 시스템을 구축하고 운영하는데 있어서 복잡성이 증가합니다.\n![](https://steemitimages.com/DQmUfQM4XqMfnNSZyvTTmrdEbMtWKCSBc4GBJb6GnvrpAv3/image.png)\n\nCMAF는 표준화된 Container 또는 캡슐화 형식을 만들어 이 문제를 해결합니다.\n![](https://steemitimages.com/DQmcLvu5spasro9PbMM6uMstwQuvV6qhTeVuRYi715JDp7a/image.png)\n기존에는 위의 그림 처럼 Encryption/Container가 나눠져 있었습니다. HLS, MPEG-DASH를 제공하기 위해서는 물리 파일이 2벌이 필요했습니다.\n\nCMAF를 통해 아래의 그림처럼 협의 되었습니다.\n![](https://steemitimages.com/DQmabwp8ZmXC59ubEce5pBjPe7U8M621YVuCqTTsxHu98Y5/image.png)\n\nContainer는 CMAF로 통일 되었지만, 아직 Encryption 부분이 남아 있습니다.\nHLS의 경우 Encryption 알고리즘으로 AES-CBC를 채택하고 있고, MPEG-DASH의 경우 AES-CTR을 채택하고 있습니다. 이 부분이 2016년까지는 풀리지 않고 있었습니다.\n\nIBC 2017(http://www,unified-streaming.com/blog/looking-back-hot-topics-ibc-2017)에서 이 부분에 대해서 논의가 있었고, 내용은 아래와 같습니다.\n\n* CMAF가 발표되었을 때, 통합 미디어 형식을 제공하겠다는 약속이 두 가지의 양립 불가능한 암호화 모드(AES-CTR, AES-CBC) 때문에 회의적이었음\n* Apple은 CBC모드를 사용하고 Google, Microsoft는 CTR모드를 사용하기에 암호화 콘텐츠를 주요 DRM 시스템에서 다루기 위해서는 두 번 암호화해야 하는 필요가 있었음\n* Google이 Widevine에 CBC 지원을 발표했고, Microsoft도 PlayReady 4.0으로 자사 제품에 CBC 지원을 통합함으로써 CMAF에서는 암호화된 미디어도 통일된 형식의 콘텐츠 제공이 가능\n\n위의 논의 이후에 Microsoft가 2018년까지 CBC를 적용하겠다는 공지를 합니다. (https://www.microsoft.com/playready/newsroom/),\n해당 링크의 PlayReady 4.0 supports CMAF interoperable format with AES-CBC and AES-CTR encryption 확인\n\n하지만, 현실에 반영되기까지는 약간의 시간이 필요해보이네요. 그래도 미디어 사업자들의 오랜 염원이었던 부분이 스펙상으로는 해소된 느낌입니다.",
      "json_metadata": "{\"tags\":[\"kr\",\"dash\",\"media\",\"hls\",\"cmaf\"],\"image\":[\"https://steemitimages.com/DQmUfQM4XqMfnNSZyvTTmrdEbMtWKCSBc4GBJb6GnvrpAv3/image.png\",\"https://steemitimages.com/DQmcLvu5spasro9PbMM6uMstwQuvV6qhTeVuRYi715JDp7a/image.png\",\"https://steemitimages.com/DQmabwp8ZmXC59ubEce5pBjPe7U8M621YVuCqTTsxHu98Y5/image.png\"],\"links\":[\"http://www\",\"https://www.microsoft.com/playready/newsroom/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "cmaf-common-media-application-format",
      "title": "CMAF (Common Media Application Format)"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:21:09",
  "trx_id": "e739cad488b419705081a0b6d89c4ed04a0d3505",
  "trx_in_block": 28,
  "virtual_op": 0
}

{
  "block": 20498777,
  "op": [
    "account_update",
    {
      "account": "giljae",
      "json_metadata": "{\"profile\":{\"name\":\"Giljae\",\"profile_image\":\"https://pbs.twimg.com/profile_images/954704293499584512/RrM8DYi7_400x400.jpg\",\"location\":\"Seoul\",\"website\":\"http://giljae.com\",\"about\":\"Slow Slow (Run Run) 내일을 사랑하오!\"}}",
      "memo_key": "STM8e6bwhYpucmTDV49uyY4CKYAe6zDebwwY83uuF8zzDJhgPhKnW"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:17:48",
  "trx_id": "db2d7b71accc07d144aad07891b9802e28e46c19",
  "trx_in_block": 61,
  "virtual_op": 0
}

{
  "block": 20498741,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"vaansteam\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:16:00",
  "trx_id": "597bf8e42cecefd2307fe528b478a0e1c2a6d490",
  "trx_in_block": 31,
  "virtual_op": 0
}

{
  "block": 20498740,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"byresteem\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T15:15:57",
  "trx_id": "b0154f00c13466789b2db4d06eb3773078e0979a",
  "trx_in_block": 45,
  "virtual_op": 0
}

{
  "block": 20496120,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "# Container Orchestrator는 무엇이며 왜 필요할까요? \n다른 용도로 사용되는 10개의 컨테이너가 있다고 가정한다면, 많은 인스턴스를 사용하고 이러한 컨테이너를 실행하는 것은 매우 쉽습니다. \n어플리케이션이 커지면서 배포한 컨테이너 수가 점점 증가하면 서로 다른 버전, 네트워크 구성을 가진 수천 개의 컨테이너를 관리할 때는 상황이 애매해집니다. \n\n컨테이너에 의존하는 개발 기술을 사용하는 회사의 경우, 이러한 유형의 아키텍처를 확장하는 문제가 발생합니다. \n오케스트레이션 인프라 스트럭처의 요점은 컨테이너를 \"스케줄링\"하는 간단한 방법을 제공하고 기본 인프라가 나머지를 수행하도록 하는 것입니다. \n\n이것이 오케트스레이션의 핵심입니다. \n\n# Container Orchestrator 살펴 보기 \nKubernetes, Mesos, ECS, Swarm 그리고 Nomad와 같이 5개의 툴이 존재합니다. 이 도구중 어떤 도구를 사용할지에 대한 결정은 회사 및 개인적 취향에 따라 달라집니다. \nLogz.io 의 경우 두개의 플랫폼으로 추렸다고 합니다. \n\nSwarm: 테스트에는 적합하지만, 상용에서 사용하기에는 부적합하다고 판단\nAmazon ECS: 클라우드에 무관심한 도구를 원했기에 ECS는 부적합하다고 판단\nNomad: 아직 사용하기에는 성숙하지 않다고 판단, 시간이 지나면 괜찮을지도... \n위 이유로 Kubernetes와 Mesos를 선정했다고 합니다.\n\n# Mesos 및 Kubernetes 정보 \nMesos는 Apache 프로젝트로 컨테이너/비컨테이너 방식을 관리할 수 있습니다.\n처음에는 Berkeley 연구 프로젝트로 사용되었고 향후 Twitter에서 사용하고 있습니다.\nMarathon 플러그인을 제공하여 컨테이너를 쉽게 관리할 수 있는 방법을 제공합니다.\n2016년에 Mesosphere가 지원하는 오픈 소스 프로젝트인 DC/OS가 도입되었고, Mesos를 더욱 단순화 하였습니다. \n\nKubernetes는 2014년에 Google에서 출시한 플랫폼이며 Cloud Native Computing Foundation에 기여했습니다. \n\n# Mesos vs. Kubernetes \nAPI에 대한 Marathon의 접근 방식은 Kubernetes와 비교하면 간단합니다.\nMarathon은 Kubernetes에 비해 적은 API 리소스를 제공합니다. \n두 플랫폼이 누리는 인기도에도 명백한 차이가 존재합니다.\n\n*kubernetes\n![](https://steemitimages.com/DQmQEN5pYqzuTeUovv7njhD56Vp5USesfmkRuZk2igrzmCf/image.png)\n\n*mesos\n![](https://steemitimages.com/DQmPbPKAJ2AUQe7M1oeCLVqT1c9fPW8EmBpwms4kSBqJvFS/image.png)\n\n위의 그림은 Kubernetes와 Mesos의 commit, contribute를 보여주고 있습니다. 압도적으로 Kubernetes의 커뮤니티 규모가 큽니다. \n\n# Kubernetes가 바른 선택인 이유 \nLogz.io에서는 처음에는 DC/OS(Mesos)를 선택했었고, Kubernetes의 강점 중 일부를 포기할 준비를 했다고 합니다. \n하지만 배포 프로세스를 자동화하는데 필요한 간단한 기능이 엔터프라이즈 버전에만 포함되어 있다는 사실을 알았다고 합니다. \nMesosphere에 문의 했었고, 이런 상황이 일시적인 것이 아닐 수 있다는 것을 깨달았다고 합니다. \nDC/OS는 이 특수한 상황을 극복해도 결국 상업 회사에 통제되기에 Kubernetes로 작업을 시작했다고 합니다. \n\n그후 Kubernetes기반으로 작업을 완료 했고, 이 변경으로 인해 새로운 코드를 하루에 여러번 배포하는 개발자들에게 모든 책임을 위임할 수 있었고, 보다 효율적이고 지속적인 배포가 가능했다고 합니다.\n\nReferences:\n* https://dzone.com/articles/kubernetes-vs-mesos-choosing-a-container-orchestra\n* https://platform9.com/blog/kubernetes-vs-mesos-marathon/",
      "json_metadata": "{\"tags\":[\"kr\",\"kubernetes\",\"mesos\"],\"image\":[\"https://steemitimages.com/DQmQEN5pYqzuTeUovv7njhD56Vp5USesfmkRuZk2igrzmCf/image.png\",\"https://steemitimages.com/DQmPbPKAJ2AUQe7M1oeCLVqT1c9fPW8EmBpwms4kSBqJvFS/image.png\"],\"links\":[\"https://dzone.com/articles/kubernetes-vs-mesos-choosing-a-container-orchestra\",\"https://platform9.com/blog/kubernetes-vs-mesos-marathon/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kr",
      "permlink": "kubernetes-vs-mesos-container-orchestrator",
      "title": "Kubernetes vs. Mesos: 어느 Container Orchestrator를 사용해야 할까? (사업 관점)"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T13:04:51",
  "trx_id": "2fd03bb0d0ee345ff232321a768b72a94d3f2023",
  "trx_in_block": 18,
  "virtual_op": 0
}

{
  "block": 20495845,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"yougotresteemed\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T12:51:06",
  "trx_id": "5006b77d0f8670408bc77bec8830dfe77140f09c",
  "trx_in_block": 15,
  "virtual_op": 0
}

{
  "block": 20495844,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"sharenow\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T12:51:03",
  "trx_id": "c253e98ae99f4a99f09c4920e79807baf9be3eb6",
  "trx_in_block": 26,
  "virtual_op": 0
}

{
  "block": 20495844,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"rmp\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T12:51:03",
  "trx_id": "0c115336482c9c05d9bde8ff1c455f20917f2faa",
  "trx_in_block": 9,
  "virtual_op": 0
}

{
  "block": 20495844,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"noganoo\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T12:51:03",
  "trx_id": "32ac5e470e9056102c96b102352a88a567c9761b",
  "trx_in_block": 1,
  "virtual_op": 0
}

{
  "block": 20481929,
  "op": [
    "author_reward",
    {
      "author": "giljae",
      "permlink": "3uujn7",
      "sbd_payout": "0.013 SBD",
      "steem_payout": "0.000 STEEM",
      "vesting_payout": "8.169175 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-08T01:14:36",
  "trx_id": "0000000000000000000000000000000000000000",
  "trx_in_block": 4294967295,
  "virtual_op": 2
}

{
  "block": 20436395,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"raise-me-up\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-06T11:12:00",
  "trx_id": "359d732e5e122be33ba0a5223764acefc705c36f",
  "trx_in_block": 11,
  "virtual_op": 0
}

{
  "block": 20436394,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"cryptoriddler\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-06T11:11:57",
  "trx_id": "82f7eb48d3316de1f3098e6c6ec899339feafc1c",
  "trx_in_block": 37,
  "virtual_op": 0
}

{
  "block": 20436394,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"artcity\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-06T11:11:57",
  "trx_id": "98b570baea0395e9390ea8c5b8471e76b7d7e918",
  "trx_in_block": 25,
  "virtual_op": 0
}

{
  "block": 20436394,
  "op": [
    "custom_json",
    {
      "id": "follow",
      "json": "[\"follow\",{\"follower\":\"giljae\",\"following\":\"a-0-0\",\"what\":[\"blog\"]}]",
      "required_auths": [],
      "required_posting_auths": [
        "giljae"
      ]
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-06T11:11:57",
  "trx_id": "ab798b16582f4274a9d9eeb1435e451860acfb13",
  "trx_in_block": 15,
  "virtual_op": 0
}

{
  "block": 20294171,
  "op": [
    "vote",
    {
      "author": "giljae",
      "permlink": "oca-open-connect-appliance-100gbps",
      "voter": "sofiaponomare",
      "weight": 10000
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T12:37:42",
  "trx_id": "9b6d70019d8dbca4d9131cd9fe903abb9d835f6f",
  "trx_in_block": 4,
  "virtual_op": 0
}

{
  "block": 20281925,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "본 글에서는 기술적 관점에서의 비교글을 작성합니다.\n\n# Kubernetes\nKubernetes는 컨테이너 어플리케이션의 automating deployment, scaling 및 관리를 위한 오픈 소스 시스템입니다. Kubernetes의 아키텍처는 아래와 같습니다.\n![](https://steemitimages.com/DQmV7zBJGTfMcxrkVuquSTomR52YVNYRkr8cArzcdVoiyuG/image.png)\n\nKubernetes Cluster와 관련된 구성 요소들은 아래와 같습니다.\n* etcd: etcd는 분산 key-value store이고, Kubernetes에서는 Master Node의 API Server가 HTTP/JSON API를 이용하여 접근할 수 있는 구성 데이터를 저장하는 용도로 사용됩니다.\n* API Server: Master Node의 Hub입니다. 다양한 Component와의 인터페이스를 원할히 해주는 역할을 담당합니다.\n* Controller Manager: 작업에 대한 부하를 조절하여 클러스터의 상태를 좋게 유지하도록 합니다.\n* Scheduler: Workload를 적절히 Node에 배치합니다.\n* Kubelet: API Server로 부터 Pod의 specificatio을 전달 받아 Host에서 수행중인 Pod를 관리합니다.\n* Master: Kubernetes Node를 제어하는 역할을 수행\n* Node: Pods가 실행되는 Machine입니다.\n\n다음은 Kubernetes와 관련된 일반적인 용어를 정리한 내용입니다.\n\n* Pods: Kubernetes는 Pod라는 그룹으로 Container를 배치하고 예약합니다. Pod의 Container는 동일한 Node에서 실행되며 리소스를 공유합니다. (e.g. File System, Kernel Namespace, IP address)\n* Deployments: Pod 그룹을 만들고 관리 할 수 있습니다. 수평적 확장이나 가용성 보장을 위해 사용됩니다.\n* Label: Object에 연결된 Key-Value 입니다. Label을 사용하여 여러 Object를 단일 세트로 검색하고 업데이트 할 수 있습니다.\n\n# Mesos + Marathon\nMesos는 Data Center에서 리소스를 동적으로 할당 하는 것을 목표로 하는 Distributed Kernel 이고, 리소스 공유 기능을 사용하는 수많은 Framework, Application Stack을 제공합니다. 각 Framework는 Scheduler와 Executor로 구성됩니다. \nMarathon은 Application 및 기타 Framework를 시작할 수 있는 Meta Framework입니다. Container Workload에 대한 확장 및 Self Healing  기능을 제공하는 Orchestration Platform 역할도 담당 할 수 있습니다. 아래 그림은 Mesos + Marathon의 아키텍처 입니다.\n![](https://steemitimages.com/DQmQ4qkfMUnfskkeBvybdh9iLU2taw8Xj7TmEn629dVpixn/image.png)\n\nMesos와 Marathone의 구성요소는 아래와 같습니다.\n* Mesos Master: Container 관리를 위한 Marathon, 대규모 데이터 처리를 위한 Spark와 NoSQL 데이터 베이스를 위한 Cassandra와 같은 Framework에서 Resource 공유를 가능하게 됩니다.\n* Mesos Slave: 사용 가능한 Resource를 Master에게 알려주는 Agent를 실행합니다.\n* Framework: Master가 Slave 노드에서 실행되는 Task를 전달 받을 수 있도록 Mesos Master에 등록됩니다.\n* Zookeeper: Cluster state를 Read/Write할 수 있는 가용성 높은 Naming Registry를 제공합니다.\n* Marathon Scheduler: Mesos Master로 부터 오퍼를 받아 Slave Node의 사용 가능한 CPU 및 Memory list를 제공합니다.\n* Docker Executor: Marathon Scheduler에서 작업을 받고 Slave Node에서 Container를 실행합니다.\n\n# Mesosphere DCOS\nMesosphere Enterprise DC/OS는 Mesos Distributed Kernel을 활용하여 Container 및 대용량 데이터 관리 및 사용자 인터페이스, 모니터링 도구 및 기타 기능을 제공합니다. 아래의 그림은 DCOS의 아키텍처 입니다.\n![](https://steemitimages.com/DQmYSXjA5VMac3fYBbqEcmcAkhHgg7rsJbB1VjYBpMtqPbq/image.png)\n\nDCOS는 Package Management, Container Orchestration, Cluster Management 및 기타 구성 요소로 구성됩니다.\n# Kubernetes vs Mesos + Marathon\n## Application Definition\n### Kubernetes\n* Application은 Pod, Deployment 및 Service의 조합을 사용하여 배포할 수 있습니다. Pod는 함께 배치된 Container Group이고 최소 배포 단위입니다. Deployment에는 여러 노드에 복제본이 존재할 수 있습니다. Service는 Container Workload의 \"external face\"이며 요청을 Round Robin 하기위해 DNS와 통합합니다.\n\n* Mesos + Marathon\nApplication은 Marathon에 의해 예약된 작업으로 Node에서 실행됩니다. Mesos의 경우에는 Application은 Marathon, Cassandra, Spark등의 Framework이며, Marathon은 Container를 Slave Node에서 실행되는 Task로 예약합니다. Marathon 1.4에서는 Kubernetes와 같은 Pod 개념을 도입하였지만 Marathon Core내의 기능은 아닙니다.\n\n## Application Scalability Constructs\n### Kubernetes\n각각의 Application 계층은 Pod로 정의되며 YAML을 사용하여 배포에 대해 선언적으로 표현합니다. 스케일링은 수동/자동으로 수행 할 수 있습니다. \n\n### Mesos + Marathon\nCLI or UI를 사용할 수 있고, JSON으로 정의하여 Docker Container의 저장소, 리소스, 인스턴스 수 및 실행할 명령을 지정할 수 있습니다. Marathon UI를 사용하여 스케일업을 수행 할 수 있고 Marathon Scheduler는 지정된 조건에 따라 Slave Node에 Container를 분배합니다.\n\n## High Availability\n### Kubernetes\nPod를 Node간에 배포하여 HA를 제공합니다. Load Balance 서비스는 유해한 Pod를 탐지하여 제거 합니다. 다중 Master Node와 Worker Node는 kubectl과 client의 요청에 대해 Workload를 조정할 수 있습니다. etcd를 Clustering하고 API Server도 복제할 수 있습니다.\n\n### Mesos + Marathon\nZookeeper를 사용하여 Mesos 및 Marathon의 HA를 지원합니다. Zookeeper는 Mesos와 Marathon의 leader를 선출하고 Clustering 상태를 유지하도록 도와줍니다.\n\n## Load Balancing\n### Kubernetes\nPods는 Service를 통해서 expose 됩니다. load balancing에 대해서는 여기를 참조하세요\n\n### Mesos + Marathon\nHost port를 여러 Container port에 매핑하는 방식을 사용합니다\n\n## Auto Scaling\n### Kubernetes\nScaling은 Deployments를 사용하여 선언적으로 정의합니다. resource metric기반의 Auto-scaling도 지원됩니다. Resource metric은 CPU, Memory 사용률과 Request, packet 및 Custom metric도 지원합니다.\n### Mesos + Marathon\nMarathon은 구동중인 Container의 Instance 개수를 지속적으로 모니터링합니다. Container중 하나가 fail나면 Marathon은 다른 Slave Node로 다시 Schedule합니다. Resource metric기반의 Auto-scaling은 지원하는 component를 통해서만 사용할 수 있습니다.\n\n## Application Upgrade and Rollback\n### Kubernetes\nRolling-update와 recreate 전략을 deployment에 모두 지원합니다.\n\n### Mesos + Marathon\nDeployment를 사용하여 Rolling-update를 지원합니다.\n\n## Health Checks\n### Kubernetes\nliveness, readiness 두가지를 지원합니다.\n\n### Mesos + Marathon\nHTTP, TCP 및 기타 프로토콜등 여러 프로토콜에서 Health check 기능을 사용할 수 있습니다.\n\n## Storage\n### Kubernetes\n두 개의 Storage API를 제공합니다.\n* Individual storage backends (e.g NFS, AWS EBS, Ceph, Focker에 대한 추상화 지원)\n* Storage resource request (다른 저장소의 리소스 요청에 대한 추상화 제공)\n\n* Block 또는 File을 지원하는 여러 유형의 Persistent volume을 제공합니다. (e.g iSCSI, NFS, FC, Amazon Web Services, Google Cloud Platform, MS Azure)\n* emptyDir volume은 비영구적이며 Container로 파일을 read/write할 수 있습니다.\n\n## Mesos + Marathon\n* Local persistent volume(Beta version)은 MySQL와 같은 상태 저장 응용 프로그램에서 지원됩니다.\n* Amazon EBS와 같은 외부 저장소 사용도 Beta version 입니다.\n* 한번에 하나의 작업에만 Volume을 첨부 할 수 있기 때문에 외부 volume를 사용하는 Application은 단일 Instance로만 확장 할 수 있습니다.\n\n## Networking\n### Kubernetes\n모든 Pod가 상호간에 통신할 수 있는 flat network model입니다. (overlay로 구현됨)\n이 모델에는 두 개의 CIDR이 필요합니다. 하나는 Pod가 IP 주소를 얻고 다른 하나는 Service에서 사용됩니다.\n\n### Mesos + Marathon\nHost mode or Bridge mode로 구성 할 수 있습니다.\n* Host mode: Host port는 Container에 의해 사용됩니다. 이로 인하여 Host에서 port 충돌이 발생할 수 있습니다.\n* Bridge mode: Container port를 매핑하여 Host port에 연결됩니다. Host port는 배포시 동적으로 할당 될 수 있습니다.\n\n## Service Discovery\n### Kubernetes\n* 환경 변수 혹은 DNS를 사용하여 찾을 수 있습니다. Pod가 실행될 때에 kubelet은 몇가지 환경 변수를 추가합니다. (\ne.g PSVCNAME_SERVICEHOST}, {SVCNAME_SERVICE_PORT}, Docker link 변수)\n* DNS server는 addon으로 사용할 수 있습니다. 전체 Cluster에서 DNS를 사용하게 되면 Pod는 자동으로 부여하는 Service Name을 사용할 수 있습니다.\n\n### Mesos + Marathon\nService는 IP, Port와 연결된 DNS 레코드를 통해 찾을 수 있습니다.\nService는 Mesos-DNS에 의해 자동으로 DNS에 레코드에 할당됩니다. 선택적으로 명명된 VIP도 작성 할 수 있습니다. VIP를 통한 요청은 LB처리가 됩니다.\n\n## Performance and Scalability\n### Kubernetes\n1.6 release에서 5000 node까지 확장됩니다. 여러 Cluster를 사용하면 5000 cluster 제한을 초과하여 사용할 수 있습니다.\n\n### Mesos + Marathon\nMesos + Marathon 조합은 확장성이 뛰어납니다. Digital Ocean에 따르면 Mesos 및 Marathon Cluster는 10000 node로 확장됩니다.\n\n# Synopsis\n## Mesos + Marathon 대비 Kubernetes의 장점\n### Kubernetes\nOn-premise SAN 및 Public Cloud를 포함한 다양한 Storage 옵션 제공\n이미 Google에서 대규모로 사용되고 있음\nContainer Orchestration 중에 가장 큰 규모의 커뮤니티를 가지고 있음\n\n### Mesos + Marathon\nAmazon EBS 및 외부 저장소는 Beta version\n상용 업체에 의해 Control 됨\n소규모 커뮤니티\n\n## Mesos + Marathon 대비 Kubernetes의 단점\n### Kubernetes\n단일 공급 업체가 없기에 사용에 대한 의사 결정이 복잡해 질 수 있음 (문제 발생시 누가 책임질 것인가?)\nKubernetes는 Container Orchestration 전용으로 제작되었음\n5000 node cluster까지 확장되고, 그 이상을 사용하려면 여러 개의 Cluster가 필요\n\n### Mesos + Marathon\n단일 공급 업체를 통해 버그 수정 및 패치를 제공 받음 (문제 발생시 책임짐)\n2-tier 아키텍처를 사용하면 다른 Framework를 배포할 수 있음\nApple, Bloomberg, Netflix내의 일부 조직에서는 10000개 이상의 node를 통해 대규모로 Mesos를 사용중 (참고: Mesosphere 블로그)\n\n## Common Features\n* Kubernetes는 오픈 소스 프로젝트이고 많은 참여가 일어나고 있음\n* Load Balancing 및 DNS와 같은 Network 기능 제공\n\n### Logging/Monitoting\n#### Kubernetes\nELK, sysdig, cAdvisor, Heapster/Grafana/InfluxDB 와 같은 외부 도구 사용 가능\n\n#### Mesos + Marathon\n내부적으로 집계 가능한 Log를 제공하고 모니터링은 외부 도구를 사용\nAuto-Scaling은 기본적으로 지원\n\n# 무엇을 선택해야 할까?\nKubernetes와 Mesos + Marathon에 대한 관심도를 살펴보면 Kubernetes가 뉴스 기사, 웹 검색, 출판물 및 Github 대상 모든 측정 항목에서 70% 이상을 차지하고 있음을 알 수 있습니다.\n![](https://steemitimages.com/DQmee5osWsu5xWEuyDGjN2pgiDnT9xTagK4siddVmw2gRqk/image.png)\n\nKubernetes는 Mesos + Marathon에 비해서 이점을 제공합니다.\n* 폭넓은 DevOps 및 Container 커뮤니티\n* 복잡한 어플리케이션 스택에 사용하기 유리하며 더 발전된 Scheduling option을 제공\n* Google에서 10년 이상의 경험을 바탕으로 제작됨\n\n결론,\n돈이 많고, 기술 내재화 하기도 싫고, 문제 발생시 책임 소재도 따지고 싶으면 Mesos + Marathon 을 선택, 그렇지 않다면 Kubernetes로 가는 것이 현실적으로 보여집니다.\n\n다음 포스팅에서는 Kubernetes와 Amazon ECS를 비교해보도록 하겠습니다.\n\n참고 자료:\n* https://thenewstack.io/a-brief-comparison-of-mesos-and-kubernetes/\n* https://platform9.com/blog/kubernetes-vs-mesos-marathon/\n* https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/",
      "json_metadata": "{\"tags\":[\"kubernets\",\"mesos\",\"marathon\",\"docker\",\"kr\"],\"image\":[\"https://steemitimages.com/DQmV7zBJGTfMcxrkVuquSTomR52YVNYRkr8cArzcdVoiyuG/image.png\",\"https://steemitimages.com/DQmQ4qkfMUnfskkeBvybdh9iLU2taw8Xj7TmEn629dVpixn/image.png\",\"https://steemitimages.com/DQmYSXjA5VMac3fYBbqEcmcAkhHgg7rsJbB1VjYBpMtqPbq/image.png\",\"https://steemitimages.com/DQmee5osWsu5xWEuyDGjN2pgiDnT9xTagK4siddVmw2gRqk/image.png\"],\"links\":[\"https://thenewstack.io/a-brief-comparison-of-mesos-and-kubernetes/\",\"https://platform9.com/blog/kubernetes-vs-mesos-marathon/\",\"https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "kubernets",
      "permlink": "kubernetes-vs-mesos-with-marathon",
      "title": "Kubernetes vs Mesos with Marathon (기술적 관점)"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:24:48",
  "trx_id": "f6c880b3c9b29893b5c35f8c4a63e9d50f5d3db8",
  "trx_in_block": 25,
  "virtual_op": 0
}

{
  "block": 20281918,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "본 글은 Netflix Tech 블로그의 내용을 번역한 내용입니다. (관심 있는 부분만...)\n원문: https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99\n\n2015년 여름, Netflix Open Connect CDN팀은 NVM Express(NVMe) 스토리지 기반의 단일 FreeBSD OCA에서 100Gbps 속도로 서비스 할 수 있도록 100GbE 네트워크 인터페이스 기술을 활용하는 프로젝트를 수행하기로 결정 했습니다.\n\n# Fake NUMA(Non-uniform Memory)\nOCA의 경우 대부분의 콘텐츠는 디스크에서 제공되며 인기있는 타이틀 10-20%만 메모리에서 제공됩니다. 초기의 NVMe 프로토타입은 디스크 대역폭 문제로 인해 제한적이었습니다.\n그래서 인기 있는 콘텐츠만 제공하는 형태로 테스트 서버에서 실험을 시작했고 모든 콘텐츠가 메모리에 저장되어 디스크 병목 현상이 발생하지 않았습니다. 의외로 성능은 40Gbps로 제한된 CPU에서 22Gbps로 떨어졌습니다.\n\npmcstat과 [Frame graph](http://www.brendangregg.com/flamegraphs.html)를 사용하여 매우 기본적인 프로파일링을 수행했습니다. 수행 결과 lock contention에 문제가 있다는 의심이 들었습니다. 그래서 DTrace기반의 lockstat으로 프로파일링을 수행했습니다. Lockstat의 결과 Inactive page queue에 대한 lock에 CPU waiting time이 많이 소요되는 것을 확인했습니다. 왜 메모리상에서 Serving을 하는데 성능이 더 나빠졌을까요?\n\nNetflix OCA는 비동기 sendfile() 시스템 호출을 통해 Nginx를 사용하여 Large 미디어 파일을 제공합니다.\n![](https://steemitimages.com/DQmaL6DuZvj8BUhbMtmrxp6FDWU7PiAAqFBCbh6GrXKUi4V/image.png)\n\n여기서 문제는 Inactive queue가 NUMA별 단일 목록으로 구성되고 single mutex lock으로 보호된다는 점입니다.\n![](https://steemitimages.com/DQmYPkZg4prPgGvswfjPKpAxEJhZZWeXfh7PGskTYUYtrbZ/image.png)\n\nNetflix가 생각해낸 해결책은 \"Fake NUMA\"입니다. 시스템에 거짓으로 2개의 CPU마다 하나의 Fake NUMA가 있다고 합니다. 이 작업후에 lock contention이 거의 사라졌으며, 52Gbps로 서비스 할 수 있었습니다. (PCIe Gen3 x8 slot)\n\n# Pbufs\nFreeBSD는 \"buf\"구조를 사용하여 디스크 I/O를 관리 합니다. Bufs는 시스템 부팅시 정적으로 할당되며 single mutex로 보호됩니다. Netflix의 문제는 sendfile() 시스템 호출이 VM paging system을 사용하여 메모리에 없을 때 디스크에서 파일을 읽는 것입니다. 결국 모든 디스크 I/O는 pbuf mutex에 제약을 받았습니다.\n\nGlobal pbuf mutex에 대한  lock contention 문제가 있었고, 이를 해결하기 위해 스왑 파티션이 아닌 파일기반으로 페이징을 처리하는 vnod pager를 수정하여 일반 커널 영역의 확장자를 사용하도록 변경했습니다. 이 변경으로 인해 잠금 경합이 제거되고 성능이 70Gbps로 향상 되었습니다.\n\n# Mbuf Page Arrays\nFreeBSD의 mbuf는 네트워크 스택의 핵심입니다. 모든 패킷은 하나 이상의 mbuf로 구성됩니다. 대량의 트래픽을 처리하기 위해서 사용하는 sendfile() system call은 mbuf내에 있는 4k page를 wrapping합니다.\n![](https://steemitimages.com/DQmQXBHaPR7Y3dGc1U3fiHsLYAH4D34LHUETfPoeu6HaYQq/image.png)\n\n여기에서의 단점은 많은 mbuf가 함께 연결된다는 것입니다. sendfile을 통과하는 1MB의 요청은 256개의 VM page를 참조할 수 있으며, 각 VM page는  mbuf로 wrapping되어 연결 됩니다.\n![](https://steemitimages.com/DQmVo1aSW18q4HcyZxUpuxyPoAWrBBDWPWwX8yyVKNxv9iZ/image.png)\n\n전송되는  mbuf의 수를 줄이기 위해 동일한 mbuf에서 동일한 유형의 여러 페이지를 전달 할 수 있도록 mbuf를 확장하기로 결정했습니다. sendfile을 위해 최대 24페이지를 전송 할 수 있는 mbuf를 설계했습니다. 그 결과 7Gbps의 성능이 향상 되었습니다.\n\n위의 작업으로 인해 FreeBSD TCP 스택을 사용하여 90Gbps에서 100% TLS 트래픽을 제공 할 수 있게 되었습니다. 그러나 RACK, BBR과 같은 고급 TCP 알고리즘을 사용할 경우 목표에 미치지 못한다는 사실을 발견했고 TCP 코드 최적화에 대한 작업을 계속 진행중입니다.\n\nNetflix는 참 대단한 회사입니다. 어디까지 성능을 끌어올릴지가 궁금하네요.",
      "json_metadata": "{\"tags\":[\"netflix\",\"oca\",\"kr\"],\"image\":[\"https://steemitimages.com/DQmaL6DuZvj8BUhbMtmrxp6FDWU7PiAAqFBCbh6GrXKUi4V/image.png\",\"https://steemitimages.com/DQmYPkZg4prPgGvswfjPKpAxEJhZZWeXfh7PGskTYUYtrbZ/image.png\",\"https://steemitimages.com/DQmQXBHaPR7Y3dGc1U3fiHsLYAH4D34LHUETfPoeu6HaYQq/image.png\",\"https://steemitimages.com/DQmVo1aSW18q4HcyZxUpuxyPoAWrBBDWPWwX8yyVKNxv9iZ/image.png\"],\"links\":[\"https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99\",\"http://www.brendangregg.com/flamegraphs.html\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "netflix",
      "permlink": "oca-open-connect-appliance-100gbps",
      "title": "OCA(Open Connect Appliance)에서 100Gbps 서비스"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:24:27",
  "trx_id": "a76ed9e27d355991d93f3b3b995a7964f69800ae",
  "trx_in_block": 21,
  "virtual_op": 0
}

{
  "block": 20281912,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "어플리케이션의 고 가용성을 설정하고 성능을 향상시키는 쉽고 가장 빠른 방법 중 하나는 LB(Load Balancer)를 이용하는 것입니다.\n로드밸런서는 세 가지 유형이 있습니다.\n* 하드웨어 기반\n* 클라우드 기반\n* 소프트웨어 기반\n\n하드웨어 로드 밸런서는 부하 분산을 제공하는 전용 장치이고 하드웨어 벤더 중 일부는 다음과 같습니다.\n* F5\n* TP-Link\n* Barracuda\n\n하드웨어 로드 밸런서는 가격이 비싸지만, 좋은 성능을 제공합니다.\n클라우드 로드 밸런서는 클라우드의 인기와 더불어 많이 사용되고 있습니다. 클라우드 로드 밸런서를 사용하는 것은 하드웨어 어플라이언스에 투자하지 않고도 관련된 모든 기능을 즐길 수 있는 저렴한 방법 중 하나입니다. 다음은 클라우드 로드 밸런서 중 일부입니다.\n* AWS\n* Google Cloud\n* Cloudflare\n* Incapsula\n* DigitalOcean\n* Azure\n\n![](https://steemitimages.com/DQmZgBBbSZZehCuhepzESnpABcS2KEtcZ9jgLdKuReYvadm/image.png)\n\n월 기준으로 20달러의 가격부터 시작할 수 있습니다.\n마지막으로 직접 설치, 관리 및 구성하는 소프트웨어 로드 밸런서가 있습니다. 오픈 소스 로드 밸런서의 목록은 다음과 같습니다.\n* Seesaw\n* LoadMaster by KEMP\n* HAProxy\n* ZEVENET\n* Neutrino\n* Balance\n* Pen\n* Nginx\n* Tradefik\n* Gobetween\n\n# Seesaw\n구글에서 제작한 Seesaw는 Go 언어로 개발되었으며, 우분투/데비안과 같은 리눅스 배포판에서 잘 동작됩니다. Anycast, DSR(Direct Server Return)을 지원하며 최소 두 개의 Seesaw 노드가 필요합니다. Baremetal환경과 가상 환경에서 동작합니다.\n기본적으로 Seesaw는 Layer 4 network에서 작동하며, Layer 7에서의 균형 조정이 필요한 경우 Option을 이용해서 사용할 수 있습니다.\n\n# KEMP\nKEMP는 AWS또는 Azure와 같은 클라우드 데이터센터에 배포하여 사용 할 수 있습니다. enter image description here\n무료이지만 상용 수준의 기능을 제공합니다.\n![](https://steemitimages.com/DQmVyucgqhTRx2QsMcQXcRK15jeKSJi4X3faAMX6w6U9XYk/image.png)\n\n* Round Robin 또는 Least connection 알고리즘을 사용하는 TCP/UDP에 대한 Layer 4 계층의 로드 밸런싱\n* Layer 7 계층의 로드 밸런싱\n* WAF(Web Application Firewall)가 내장되어 있음\n* IPS(Intrusion Prevention Engine)가 내장되어 있음\n* Global 로드 밸런싱, 다중 사이트 지원\n* Caching, 콘텐츠 압축, 콘텐츠 스위칭 지원\n* Web cookie persistence\n* IPSec tunneling\n\nKEMP 로드 밸런서는 Apple, Sony, JP Morgan, Audi, Hyundai 등의 대형 회사에서 사용되고 있습니다. 무료 버전으로도 충분한 기능을 제공하지만, 더 많은 기능이 필요할 경우 상용 라이센스를 구입해야 합니다.\n\n# HAProxy\nHigh-availability, Proxy, TCP/HTTP 로드 밸런싱을 지원하는 제품입니다. HAProxy는 아래의 회사에서 사용하고 있습니다.\n* Airbnb\n* Github\n* Imgur\n* MaxCDN\n* Reddit\n\n기능은 다음과 같습니다.\n* Support IPv6 and Unix socket\n* Deflate & Gzip compression\n* HEalth-check\n* Source-based session stickiness\n* 통계 레포팅 기능이 내장되어 있음\n\n# Zevenet\nZevenet은 L3, L4, L7을 지원합니다.\n![](https://steemitimages.com/DQmSGv7BGB7hGS5TgvzXFFYEcP82eesh8rxc1MFmdDHtQDg/image.png)\n\nAdvanced health-check 모니터링을 지원 하기에 끊김없는 사용자 경험을 제공합니다. Zen으로 알려진 Zevenet은 FTP, SIP, SSL, HTTP등과 같은 TCP기반 프로토콜을 지원합니다.\n\n# Neutrino\nNeutrino는 Ebay에서 사용하고 있으며, Scala & Netty를 사용하여 개발되었습니다. Least-connection, Round-robin 알고리즘을 지원합니다.\n* Using canonical names\n* Context-based\n* L4 using TCP port numbers\n\n[](https://steemitimages.com/DQmaTc3C6SUn2kxT1Mdh79rYrv8ewrYpRdJveMxDkktQto6/image.png)\n\nNeutrino는 2 Core VM에서 초당 300개의 요청 처리가 가능합니다. HAProxy와 비교시 Neutrino를 사용할 때의 주요 이점은 L7 스위칭입니다.\n항상 그렇듯이 두 가지 방법을 모두 사용하고 환경에 가장 적합한 것을 고려해야 합니다.\n\n# Balance\n기본적은 로드 밸런싱 기능을 지니고 있습니다.\n\n# Pen\nPen은 로드 밸런싱의 기본 기능과 함께 아래 기능을 제공합니다.\n* GeoIP 필터\n* SSL 종료\n* IPv4 및 IPv6 호환성\n\n# Nginx\n오픈 소스 Nginx는 기본 수준의 콘텐츠 스위칭 및 여러 서버에 대한 라우팅을 지원합니다. Nginx Plus의 경우는 그 이상의 기능을 제공합니다. 로드 밸런싱, 콘텐츠 캐싱, 웹 서버, WAF, 모니터링등을 포함한 All-in-one web application delivery solution을 제공합니다. 초당 수백만 건의 요청을 처리 할 수 있는 확장형 어플리케이션을 위한 고성능 로드 밸런서 솔루션도 제공 합니다.\n\n# Traefik\nHTTP reserve proxy와 로드 밸런서를 제공합니다. 또한 여러 백엔드 서비스를 지원합니다. (Amazon ECS, Docker, Kubernetes, Rancher.,)\n[](https://steemitimages.com/DQmRN6eUUTabntxxdGBmBBGL7c3RuEoENfb6sqenF1ZdVN4/image.png)\n\nWeb socket, HTTP/2, 자동 SSL 인증서 갱신, 암호 관리, 리소스 관리 및 모니터링을 위한 Interface를 제공합니다.\n\n# Gobetween\nLightweight하지만 강력한 고성능 L4 TCP, TLS 및 UDP 기반의 로드 밸런서 입니다.\n[](https://steemitimages.com/DQmUhBZigp9rnqocyapPbskV6wS1dKy67cC9hFKuWtxmEuu/image.png)\n\nWindows, Linux, Docker, Darwin과 같은 멀티 플랫폼에서 동작합니다. 로드 밸런싱은 구성에서 설정해야 합니다. 아래의 알고리즘 기반으로 수행됩니다.\n* IP 해시\n* Round-robin\n* Least bandwidth\n* Least connection\n* Weight\n\n아래의 벤치마크 정보를 기준으로 Gobetween은 HAProxy보다 빠르지만 Nginx보다는 느립니다.\n[](https://steemitimages.com/DQmZNXmTVN6cUX7bJGFxvBvkNCBjGHFUifqdkCT5U2HRyUv/image.png)\n\n동적 환경을 위한 자동 검색 기능을 탑재한 최신 L4 로드 밸런서를 찾고 있다면 Gobetween이 유망할 것으로 보여집니다.\n위의 정보를 기준으로 각 상황에 맞는 로드 밸런서를 선택하시길 바랍니다.",
      "json_metadata": "{\"tags\":[\"lb\",\"loadbalancer\",\"kr\"],\"image\":[\"https://steemitimages.com/DQmZgBBbSZZehCuhepzESnpABcS2KEtcZ9jgLdKuReYvadm/image.png\",\"https://steemitimages.com/DQmVyucgqhTRx2QsMcQXcRK15jeKSJi4X3faAMX6w6U9XYk/image.png\",\"https://steemitimages.com/DQmSGv7BGB7hGS5TgvzXFFYEcP82eesh8rxc1MFmdDHtQDg/image.png\"],\"links\":[\"https://steemitimages.com/DQmaTc3C6SUn2kxT1Mdh79rYrv8ewrYpRdJveMxDkktQto6/image.png\",\"https://steemitimages.com/DQmRN6eUUTabntxxdGBmBBGL7c3RuEoENfb6sqenF1ZdVN4/image.png\",\"https://steemitimages.com/DQmUhBZigp9rnqocyapPbskV6wS1dKy67cC9hFKuWtxmEuu/image.png\",\"https://steemitimages.com/DQmZNXmTVN6cUX7bJGFxvBvkNCBjGHFUifqdkCT5U2HRyUv/image.png\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "lb",
      "permlink": "load-balancer",
      "title": "Load Balancer 비교"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:24:09",
  "trx_id": "c9709eeec8f9bdc402177dad039a243ae70db2ed",
  "trx_in_block": 20,
  "virtual_op": 0
}

{
  "block": 20281884,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "어플리케이션의 고 가용성을 설정하고 성능을 향상시키는 쉽고 가장 빠른 방법 중 하나는 LB(Load Balancer)를 이용하는 것입니다.\n로드밸런서는 세 가지 유형이 있습니다.\n* 하드웨어 기반\n* 클라우드 기반\n* 소프트웨어 기반\n\n하드웨어 로드 밸런서는 부하 분산을 제공하는 전용 장치이고 하드웨어 벤더 중 일부는 다음과 같습니다.\n* F5\n* TP-Link\n* Barracuda\n\n하드웨어 로드 밸런서는 가격이 비싸지만, 좋은 성능을 제공합니다.\n클라우드 로드 밸런서는 클라우드의 인기와 더불어 많이 사용되고 있습니다. 클라우드 로드 밸런서를 사용하는 것은 하드웨어 어플라이언스에 투자하지 않고도 관련된 모든 기능을 즐길 수 있는 저렴한 방법 중 하나입니다. 다음은 클라우드 로드 밸런서 중 일부입니다.\n* AWS\n* Google Cloud\n* Cloudflare\n* Incapsula\n* DigitalOcean\n* Azure\n\n![](https://steemitimages.com/DQmZgBBbSZZehCuhepzESnpABcS2KEtcZ9jgLdKuReYvadm/image.png)\n\n월 기준으로 20달러의 가격부터 시작할 수 있습니다.\n마지막으로 직접 설치, 관리 및 구성하는 소프트웨어 로드 밸런서가 있습니다. 오픈 소스 로드 밸런서의 목록은 다음과 같습니다.\n* Seesaw\n* LoadMaster by KEMP\n* HAProxy\n* ZEVENET\n* Neutrino\n* Balance\n* Pen\n* Nginx\n* Tradefik\n* Gobetween\n\n# Seesaw\n구글에서 제작한 Seesaw는 Go 언어로 개발되었으며, 우분투/데비안과 같은 리눅스 배포판에서 잘 동작됩니다. Anycast, DSR(Direct Server Return)을 지원하며 최소 두 개의 Seesaw 노드가 필요합니다. Baremetal환경과 가상 환경에서 동작합니다.\n기본적으로 Seesaw는 Layer 4 network에서 작동하며, Layer 7에서의 균형 조정이 필요한 경우 Option을 이용해서 사용할 수 있습니다.\n\n# KEMP\nKEMP는 AWS또는 Azure와 같은 클라우드 데이터센터에 배포하여 사용 할 수 있습니다. enter image description here\n무료이지만 상용 수준의 기능을 제공합니다.\n![](https://steemitimages.com/DQmVyucgqhTRx2QsMcQXcRK15jeKSJi4X3faAMX6w6U9XYk/image.png)\n\n* Round Robin 또는 Least connection 알고리즘을 사용하는 TCP/UDP에 대한 Layer 4 계층의 로드 밸런싱\n* Layer 7 계층의 로드 밸런싱\n* WAF(Web Application Firewall)가 내장되어 있음\n* IPS(Intrusion Prevention Engine)가 내장되어 있음\n* Global 로드 밸런싱, 다중 사이트 지원\n* Caching, 콘텐츠 압축, 콘텐츠 스위칭 지원\n* Web cookie persistence\n* IPSec tunneling\n\nKEMP 로드 밸런서는 Apple, Sony, JP Morgan, Audi, Hyundai 등의 대형 회사에서 사용되고 있습니다. 무료 버전으로도 충분한 기능을 제공하지만, 더 많은 기능이 필요할 경우 상용 라이센스를 구입해야 합니다.\n\n# HAProxy\nHigh-availability, Proxy, TCP/HTTP 로드 밸런싱을 지원하는 제품입니다. HAProxy는 아래의 회사에서 사용하고 있습니다.\n* Airbnb\n* Github\n* Imgur\n* MaxCDN\n* Reddit\n\n기능은 다음과 같습니다.\n* Support IPv6 and Unix socket\n* Deflate & Gzip compression\n* HEalth-check\n* Source-based session stickiness\n* 통계 레포팅 기능이 내장되어 있음\n\n# Zevenet\nZevenet은 L3, L4, L7을 지원합니다.\n![](https://steemitimages.com/DQmSGv7BGB7hGS5TgvzXFFYEcP82eesh8rxc1MFmdDHtQDg/image.png)\n\nAdvanced health-check 모니터링을 지원 하기에 끊김없는 사용자 경험을 제공합니다. Zen으로 알려진 Zevenet은 FTP, SIP, SSL, HTTP등과 같은 TCP기반 프로토콜을 지원합니다.\n\n# Neutrino\nNeutrino는 Ebay에서 사용하고 있으며, Scala & Netty를 사용하여 개발되었습니다. Least-connection, Round-robin 알고리즘을 지원합니다.\n* Using canonical names\n* Context-based\n* L4 using TCP port numbers\n\n[](https://steemitimages.com/DQmaTc3C6SUn2kxT1Mdh79rYrv8ewrYpRdJveMxDkktQto6/image.png)\n\nNeutrino는 2 Core VM에서 초당 300개의 요청 처리가 가능합니다. HAProxy와 비교시 Neutrino를 사용할 때의 주요 이점은 L7 스위칭입니다.\n항상 그렇듯이 두 가지 방법을 모두 사용하고 환경에 가장 적합한 것을 고려해야 합니다.\n\n# Balance\n기본적은 로드 밸런싱 기능을 지니고 있습니다.\n\n# Pen\nPen은 로드 밸런싱의 기본 기능과 함께 아래 기능을 제공합니다.\n* GeoIP 필터\n* SSL 종료\n* IPv4 및 IPv6 호환성\n\n# Nginx\n오픈 소스 Nginx는 기본 수준의 콘텐츠 스위칭 및 여러 서버에 대한 라우팅을 지원합니다. Nginx Plus의 경우는 그 이상의 기능을 제공합니다. 로드 밸런싱, 콘텐츠 캐싱, 웹 서버, WAF, 모니터링등을 포함한 All-in-one web application delivery solution을 제공합니다. 초당 수백만 건의 요청을 처리 할 수 있는 확장형 어플리케이션을 위한 고성능 로드 밸런서 솔루션도 제공 합니다.\n\n# Traefik\nHTTP reserve proxy와 로드 밸런서를 제공합니다. 또한 여러 백엔드 서비스를 지원합니다. (Amazon ECS, Docker, Kubernetes, Rancher.,)\n[](https://steemitimages.com/DQmRN6eUUTabntxxdGBmBBGL7c3RuEoENfb6sqenF1ZdVN4/image.png)\n\nWeb socket, HTTP/2, 자동 SSL 인증서 갱신, 암호 관리, 리소스 관리 및 모니터링을 위한 Interface를 제공합니다.\n\n# Gobetween\nLightweight하지만 강력한 고성능 L4 TCP, TLS 및 UDP 기반의 로드 밸런서 입니다.\n[](https://steemitimages.com/DQmUhBZigp9rnqocyapPbskV6wS1dKy67cC9hFKuWtxmEuu/image.png)\n\nWindows, Linux, Docker, Darwin과 같은 멀티 플랫폼에서 동작합니다. 로드 밸런싱은 구성에서 설정해야 합니다. 아래의 알고리즘 기반으로 수행됩니다.\n* IP 해시\n* Round-robin\n* Least bandwidth\n* Least connection\n* Weight\n\n아래의 벤치마크 정보를 기준으로 Gobetween은 HAProxy보다 빠르지만 Nginx보다는 느립니다.\n[](https://steemitimages.com/DQmZNXmTVN6cUX7bJGFxvBvkNCBjGHFUifqdkCT5U2HRyUv/image.png)\n\n동적 환경을 위한 자동 검색 기능을 탑재한 최신 L4 로드 밸런서를 찾고 있다면 Gobetween이 유망할 것으로 보여집니다.\n위의 정보를 기준으로 각 상황에 맞는 로드 밸런서를 선택하시길 바랍니다.",
      "json_metadata": "{\"tags\":[\"lb\",\"loadbalancer\"],\"image\":[\"https://steemitimages.com/DQmZgBBbSZZehCuhepzESnpABcS2KEtcZ9jgLdKuReYvadm/image.png\",\"https://steemitimages.com/DQmVyucgqhTRx2QsMcQXcRK15jeKSJi4X3faAMX6w6U9XYk/image.png\",\"https://steemitimages.com/DQmSGv7BGB7hGS5TgvzXFFYEcP82eesh8rxc1MFmdDHtQDg/image.png\"],\"links\":[\"https://steemitimages.com/DQmaTc3C6SUn2kxT1Mdh79rYrv8ewrYpRdJveMxDkktQto6/image.png\",\"https://steemitimages.com/DQmRN6eUUTabntxxdGBmBBGL7c3RuEoENfb6sqenF1ZdVN4/image.png\",\"https://steemitimages.com/DQmUhBZigp9rnqocyapPbskV6wS1dKy67cC9hFKuWtxmEuu/image.png\",\"https://steemitimages.com/DQmZNXmTVN6cUX7bJGFxvBvkNCBjGHFUifqdkCT5U2HRyUv/image.png\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "lb",
      "permlink": "load-balancer",
      "title": "Load Balancer 비교"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:22:45",
  "trx_id": "c577fa46c1b6f9860a67e5cbb3902e6283606eeb",
  "trx_in_block": 22,
  "virtual_op": 0
}

{
  "block": 20281599,
  "op": [
    "delegate_vesting_shares",
    {
      "delegatee": "giljae",
      "delegator": "steem",
      "vesting_shares": "29623.962899 VESTS"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:08:30",
  "trx_id": "21a239e6143996bc468fac583e8e700520bb30d0",
  "trx_in_block": 38,
  "virtual_op": 0
}

{
  "block": 20281536,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "@@ -569,17 +569,16 @@\n mcstat%EA%B3%BC \n-!\n %5BFrame g\n",
      "json_metadata": "{\"tags\":[\"netflix\",\"oca\"],\"image\":[\"https://steemitimages.com/DQmaL6DuZvj8BUhbMtmrxp6FDWU7PiAAqFBCbh6GrXKUi4V/image.png\",\"https://steemitimages.com/DQmYPkZg4prPgGvswfjPKpAxEJhZZWeXfh7PGskTYUYtrbZ/image.png\",\"https://steemitimages.com/DQmQXBHaPR7Y3dGc1U3fiHsLYAH4D34LHUETfPoeu6HaYQq/image.png\",\"https://steemitimages.com/DQmVo1aSW18q4HcyZxUpuxyPoAWrBBDWPWwX8yyVKNxv9iZ/image.png\"],\"links\":[\"https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99\",\"http://www.brendangregg.com/flamegraphs.html\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "netflix",
      "permlink": "oca-open-connect-appliance-100gbps",
      "title": "OCA(Open Connect Appliance)에서 100Gbps 서비스"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:05:21",
  "trx_id": "25f7389a26a919fdb7b447093a6b68adae7917ed",
  "trx_in_block": 48,
  "virtual_op": 0
}

{
  "block": 20281521,
  "op": [
    "comment",
    {
      "author": "giljae",
      "body": "본 글은 Netflix Tech 블로그의 내용을 번역한 내용입니다. (관심 있는 부분만...)\n원문: https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99\n\n2015년 여름, Netflix Open Connect CDN팀은 NVM Express(NVMe) 스토리지 기반의 단일 FreeBSD OCA에서 100Gbps 속도로 서비스 할 수 있도록 100GbE 네트워크 인터페이스 기술을 활용하는 프로젝트를 수행하기로 결정 했습니다.\n\n# Fake NUMA(Non-uniform Memory)\nOCA의 경우 대부분의 콘텐츠는 디스크에서 제공되며 인기있는 타이틀 10-20%만 메모리에서 제공됩니다. 초기의 NVMe 프로토타입은 디스크 대역폭 문제로 인해 제한적이었습니다.\n그래서 인기 있는 콘텐츠만 제공하는 형태로 테스트 서버에서 실험을 시작했고 모든 콘텐츠가 메모리에 저장되어 디스크 병목 현상이 발생하지 않았습니다. 의외로 성능은 40Gbps로 제한된 CPU에서 22Gbps로 떨어졌습니다.\n\npmcstat과 ![Frame graph](http://www.brendangregg.com/flamegraphs.html)를 사용하여 매우 기본적인 프로파일링을 수행했습니다. 수행 결과 lock contention에 문제가 있다는 의심이 들었습니다. 그래서 DTrace기반의 lockstat으로 프로파일링을 수행했습니다. Lockstat의 결과 Inactive page queue에 대한 lock에 CPU waiting time이 많이 소요되는 것을 확인했습니다. 왜 메모리상에서 Serving을 하는데 성능이 더 나빠졌을까요?\n\nNetflix OCA는 비동기 sendfile() 시스템 호출을 통해 Nginx를 사용하여 Large 미디어 파일을 제공합니다.\n![](https://steemitimages.com/DQmaL6DuZvj8BUhbMtmrxp6FDWU7PiAAqFBCbh6GrXKUi4V/image.png)\n\n여기서 문제는 Inactive queue가 NUMA별 단일 목록으로 구성되고 single mutex lock으로 보호된다는 점입니다.\n![](https://steemitimages.com/DQmYPkZg4prPgGvswfjPKpAxEJhZZWeXfh7PGskTYUYtrbZ/image.png)\n\nNetflix가 생각해낸 해결책은 \"Fake NUMA\"입니다. 시스템에 거짓으로 2개의 CPU마다 하나의 Fake NUMA가 있다고 합니다. 이 작업후에 lock contention이 거의 사라졌으며, 52Gbps로 서비스 할 수 있었습니다. (PCIe Gen3 x8 slot)\n\n# Pbufs\nFreeBSD는 \"buf\"구조를 사용하여 디스크 I/O를 관리 합니다. Bufs는 시스템 부팅시 정적으로 할당되며 single mutex로 보호됩니다. Netflix의 문제는 sendfile() 시스템 호출이 VM paging system을 사용하여 메모리에 없을 때 디스크에서 파일을 읽는 것입니다. 결국 모든 디스크 I/O는 pbuf mutex에 제약을 받았습니다.\n\nGlobal pbuf mutex에 대한  lock contention 문제가 있었고, 이를 해결하기 위해 스왑 파티션이 아닌 파일기반으로 페이징을 처리하는 vnod pager를 수정하여 일반 커널 영역의 확장자를 사용하도록 변경했습니다. 이 변경으로 인해 잠금 경합이 제거되고 성능이 70Gbps로 향상 되었습니다.\n\n# Mbuf Page Arrays\nFreeBSD의 mbuf는 네트워크 스택의 핵심입니다. 모든 패킷은 하나 이상의 mbuf로 구성됩니다. 대량의 트래픽을 처리하기 위해서 사용하는 sendfile() system call은 mbuf내에 있는 4k page를 wrapping합니다.\n![](https://steemitimages.com/DQmQXBHaPR7Y3dGc1U3fiHsLYAH4D34LHUETfPoeu6HaYQq/image.png)\n\n여기에서의 단점은 많은 mbuf가 함께 연결된다는 것입니다. sendfile을 통과하는 1MB의 요청은 256개의 VM page를 참조할 수 있으며, 각 VM page는  mbuf로 wrapping되어 연결 됩니다.\n![](https://steemitimages.com/DQmVo1aSW18q4HcyZxUpuxyPoAWrBBDWPWwX8yyVKNxv9iZ/image.png)\n\n전송되는  mbuf의 수를 줄이기 위해 동일한 mbuf에서 동일한 유형의 여러 페이지를 전달 할 수 있도록 mbuf를 확장하기로 결정했습니다. sendfile을 위해 최대 24페이지를 전송 할 수 있는 mbuf를 설계했습니다. 그 결과 7Gbps의 성능이 향상 되었습니다.\n\n위의 작업으로 인해 FreeBSD TCP 스택을 사용하여 90Gbps에서 100% TLS 트래픽을 제공 할 수 있게 되었습니다. 그러나 RACK, BBR과 같은 고급 TCP 알고리즘을 사용할 경우 목표에 미치지 못한다는 사실을 발견했고 TCP 코드 최적화에 대한 작업을 계속 진행중입니다.\n\nNetflix는 참 대단한 회사입니다. 어디까지 성능을 끌어올릴지가 궁금하네요.",
      "json_metadata": "{\"tags\":[\"netflix\",\"oca\"],\"image\":[\"http://www.brendangregg.com/flamegraphs.html\",\"https://steemitimages.com/DQmaL6DuZvj8BUhbMtmrxp6FDWU7PiAAqFBCbh6GrXKUi4V/image.png\",\"https://steemitimages.com/DQmYPkZg4prPgGvswfjPKpAxEJhZZWeXfh7PGskTYUYtrbZ/image.png\",\"https://steemitimages.com/DQmQXBHaPR7Y3dGc1U3fiHsLYAH4D34LHUETfPoeu6HaYQq/image.png\",\"https://steemitimages.com/DQmVo1aSW18q4HcyZxUpuxyPoAWrBBDWPWwX8yyVKNxv9iZ/image.png\"],\"links\":[\"https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99\"],\"app\":\"steemit/0.1\",\"format\":\"markdown\"}",
      "parent_author": "",
      "parent_permlink": "netflix",
      "permlink": "oca-open-connect-appliance-100gbps",
      "title": "OCA(Open Connect Appliance)에서 100Gbps 서비스"
    }
  ],
  "op_in_trx": 0,
  "timestamp": "2018-03-01T02:04:36",
  "trx_id": "0db8f3c3602f2483a2bb1023cc84ec672b062f82",
  "trx_in_block": 33,
  "virtual_op": 0
}