Skip to content
Published on

韓国の開発ブログ名文キュレーション 1 — バックエンドとインフラ、直接開いて確認した14本

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

このシリーズはランキングではなく編集者の選択です

この記事は、韓国語で書かれた開発記事のうち読む価値のあるものを選んで紹介する全6回シリーズの第1回です。

まず選定方法を明かします。検索で候補を見つけたあと、記事を直接開いて確認し、そのなかから説明が具体的で再現可能なものを選びました。何が再現可能な説明なのかという基準は単純です。症状と原因と根拠がそれぞれ別に書かれていて、読む人が自分の環境で同じ確認をしてみられるなら再現可能な記事です。逆に結論だけがあって、その結論に至った観測がなければ、どれほど正しいことでもこのリストには入れませんでした。

ここにランキングはありません。閲覧数も人気も影響力も測定していません。私にはそうした数字にアクセスする手段がなく、あるふりをするつもりもありません。このリストは編集者の選択です。 別の人が同じ基準で選んでいたら、半分ほどは違う記事が入っていたはずです。

出典は個人ブログを優先しました。Tistory、velog、個人ドメイン、GitHub Pagesの順に見て、企業の技術ブログはそのテーマの定本であるときだけ入れました。この記事にはWoowacourseのTecobleが1本、その例として入っています。

韓国国外の読者に向けて、もう一点重要なことを。リンク先は韓国語です。 読むには韓国語が必要です。機械翻訳でも大筋は追えますが、論旨を支えるコードやコマンド出力はもともと言語に依存しません。

リンクは2026-08-12に直接開いて確認しました。個人ブログの記事は消えたりURLが変わったりすることがあります。

サービスメッシュとプロキシ — トラフィックが通る道を設定として扱う

アプリケーションコードからリトライとタイムアウトを取り除いても、そのロジックは消えるのではなくプロキシへ移ります。移った先でそれがどんな姿をしているかを知っている人は、意外に少ないものです。

Istio Sidecar로 서비스 구성 범위 좁히기

  • ブログ · 著者: Outsider's Dev Story
  • 一行要約: IstioのSidecarリソースでワークロードが見られるサービスの範囲を狭める方法と、それがなぜ必要かを扱います。
  • こんな人に: クラスタが大きくなり、サイドカープロキシのメモリと設定伝播量が負担になり始めた人。

この記事がまず良いのは、名前の混同を先に整理してから入る点です。IstioのSidecarはサイドカーパターンそのものではなくCRDの名前で、この二つを混ぜて使うとドキュメントが読めなくなります。そのあとxDSプロトコルがどう分かれているかを押さえ、設定範囲を狭めるという概念がその上でどう働くかを説明します。フロントエンドのサービスが使うはずのないネームスペースまで知る必要はない、という具体例が付いているので、読み終えると自分のクラスタから何を消してよいか判断できます。概念説明と実習が切り離されず一つの流れになっているのも長所です。

Istio ServiceEntry로 외부 서비스 등록하기

  • ブログ · 著者: Outsider's Dev Story
  • 一行要約: メッシュ外の外部APIをServiceEntryで登録し、メッシュ内のポリシーと観測対象に含める方法を整理します。
  • こんな人に: 外部の決済や地図APIを呼んでいるのに、その呼び出しだけが観測の死角として残っている人。

外へ出るトラフィックをどう扱うかを決める設定が先に出てきます。全部塞ぐか、全部開けるか、登録されたものだけ開けるかという選択で、この選択が後の障害調査の難易度を決めます。記事は選択肢を並べるだけでなく、それぞれがどんな状況で妥当かを添えています。ServiceEntryで登録すればそこから外部呼び出しにもサーキットブレーキングとロギングとメトリクスが付く、という箇所がこの記事の核です。前のSidecarの記事と続けて読むと、メッシュの境界がどこまでなのかという絵が完成します。

Istio External Authorization의 로컬리티 로드 밸런싱 확인하기

  • ブログ · 著者: Outsider's Dev Story
  • 一行要約: 外部認可サービスを付けたときにもロケーリティベースのロードバランシングが効くのかを、Kindクラスタで直接確認します。
  • こんな人に: ドキュメントに書かれた動作をそのまま信じる前に一度再現してみる習慣を付けたい人。

この記事の価値は結論より方法にあります。疑問が出たときにKindでクラスタを立て、Envoyのクラスタ設定を取り出し、トラフィック分布のメトリクスを確認するという順序そのものが、そのまま学ぶに値する手順です。結果としてロケーリティロードバランシングが効くことを確認しますが、もし効いていなくてもこの記事は良い記事のままだったはずです。確認の過程が再現可能に書かれているからです。サービスメッシュを導入した組織でこの検証を誰がやるべきかと問われたら、この記事がその答えの形を見せてくれます。

[Envoy 이해하기] Circuit_Breaker (outlier_detection)

  • ブログ · 著者: 사바라다는 차곡차곡
  • 一行要約: Envoyがoutlier detectionでサーキットブレーカーを実装する仕組みを、失敗するバックエンドを作って実際に外れるか観察しながら説明します。
  • こんな人に: サーキットブレーカーをライブラリでしか使ったことがなく、プロキシ層ではどんな姿なのか気になる人。

サーキットブレーカーを説明する記事は多いのですが、たいていは状態遷移図で終わります。この記事は連続エラーが何回たまるとそのインスタンスがロードバランサのプールから外れるのかを、実際に作って確認します。テストシナリオが付いているので、設定値の意味がドキュメントの説明ではなく観測された動作として理解できます。アプリケーションレベルのサーキットブレーカーとプロキシレベルのそれが、どう違う問題を解いているのかも自然に見えてきます。

[proxy] Envoy 이해하기 - Routing

  • ブログ · 著者: 사바라다는 차곡차곡
  • 一行要約: Envoyの四つのルーティング方式をパス、重み、ホスト、ヘッダー基準に分け、設定例とともに整理します。
  • こんな人に: カナリアデプロイやA/Bテストをプロキシ設定だけで処理したい人。

重みルーティングが段階的デプロイに、ヘッダールーティングがA/Bテストに使われるという対応が明示されているので、機能の一覧ではなく使いどころの一覧として読めます。四つそれぞれに設定例とテスト結果まで付いているため、コピーして始めるのに向いています。前のサーキットブレーカーの記事と同じシリーズなので、続けて読んでも用語がぶれないのも長所です。Istioを使っているなら結局その下で動いているのはこれらの設定だ、という点で実用的です。

ランタイムと可観測性 — プロセスの中で起きていることを外から見る

インフラをどれだけうまく組んでも、プロセスの中で何が起きているか分からなければ調査できません。この節の記事はその内側を扱います。

[Server] 프로메테우스와 푸시 게이트웨이의 한계(Prometheus and limits of Push Gateway)

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: Prometheusのプル方式とプッシュ方式を比較したうえで、PushGatewayの内部構造とそこから来る限界を説明します。
  • こんな人に: バッチジョブのメトリクスを残そうとPushGatewayを導入しかけて立ち止まった人。

この記事が珍しいのは、ツールの使い方ではなく限界を扱っているからです。シングルスレッド処理、グローバルミューテックス、寿命の短いラベルがたまったときのメモリ問題まで降りていき、なぜPushGatewayが万能の解ではないのかを構造として説明します。導入の可否を決めなければならない人にとっては、機能紹介よりこういう記事のほうがはるかに役立ちます。プル方式が基本である理由に納得すると、可観測性の設計全般の判断が変わります。

JVM 메모리 구조와 GC

  • ブログ · 著者: 기계인간 John Grib
  • 一行要約: 世代別メモリ構造がなぜそういう形なのかを弱い世代仮説から解きほぐし、Serial系とParallel系とConcurrent系のコレクタを比較します。
  • こんな人に: GCオプションを検索して貼ったことはあるが、なぜそのオプションなのかは説明できない人。

この記事の美点は順序です。構造を先に見せ、その構造がどんな仮説の上に立っているかを説明するので、コレクタごとの違いが恣意的な一覧ではなく同じ問題への別の答えとして読めます。Oracle公式ドキュメントへの参照が細かく付いていて、さらに掘る経路も開いています。2019年に書かれ2022年に更新された記事なので最新のコレクタまでは扱いませんが、基礎を固める用途には今も十分です。ウィキ形式なので必要な節だけ拾い読みしやすいのも助かります。

[JVM] 클래스 패스 섀도잉(Classpath Shadowing)이란?

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: 同じ名前のクラスがクラスパスに複数あるとき、クラスローダが何を選ぶのか、その結果どんな事故が起きるのかを説明します。
  • こんな人に: ライブラリのバージョンを上げたらランタイムでだけ妙な例外が出る状況に遭ったことのある人。

依存地獄と一括りに呼ばれる現象のかなりの部分が、この記事が説明する一つの規則から生まれます。クラスローダが最初に見つけたものを固定するという規則で、この一文を知っているかどうかが調査時間を時間単位で分けます。ブートストラップとプラットフォームとアプリケーションローダの階層を押さえてくれるので、どこで衝突したかを追う位置も定まります。概念の記事ですが、実務ですぐに取り出して使える種類のものです。

[Kafka] 카프카 파티션 증설 시 컨슈머의 auto.offset.reset 설정 주의사항

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: パーティションを増やす瞬間、コンシューマのオフセット初期化設定によってはメッセージが失われうることを図とともに説明します。
  • こんな人に: スループットが足りずパーティションを増やす計画があり、無停止でやりたい人。

デフォルトのままにしておくと増設中に届いたメッセージが捨てられうる、というのがこの記事の結論で、その結論に至る過程が段階ごとに描かれています。Kafkaの運用でパーティション増設は取り消せない作業なので、事前に一度読んでおく価値は十分にあります。設定一つがデータ損失につながる経路を見せてくれる記事は、思ったより多くありません。増設の計画書にそのまま引用できる注意事項がまとまっています。

サーバーとネットワークの基礎 — 長く使えるもの

ツールは変わりますが、この節の内容はあまり変わりません。数年前の記事が今も有効な理由です。

리눅스 서버 60초안에 상황파악하기

  • ブログ · 著者: Luavis' Dev Story
  • 一行要約: Netflixの60秒チェックリストを移しながら、十ほどのコマンドをUSE方法論の基準でまとめて説明します。
  • こんな人に: サーバーに入ったはいいが、毎回何から打つべきか迷う人。

遅いサーバーの前で必要なのは深い知識より順序です。この記事はその順序を与え、各コマンドが何を教えてくれるかを利用率と飽和とエラーという軸で整理してくれます。2017年の記事ですが扱うコマンドが根本的なものなので、今そのまま使ってもずれません。障害対応ドキュメントの最初のページとして貼っておくのに向いた種類の記事です。

[Linux] top 명령어로 서버의 상태 파악하기

  • ブログ · 著者: 사바라다는 차곡차곡
  • 一行要約: topの出力を要約領域とプロセス領域に分けて一つずつ解釈し、対話キーまで整理します。
  • こんな人に: topを毎日打っているが、上のほうの数字のいくつかはまだ正確には分かっていない人。

前の記事が順序を与えるなら、この記事はその順序の最後のマスを埋めます。ロードアベレージとCPU状態の項目とメモリ表示をそれぞれ何として読むべきかを押さえ、ソートとフィルタとスレッド表示のような対話操作まで扱います。これだけ分かっていると、topの一画面から得る情報量が明らかに変わります。基本のツールを最後まで使い切るほうが、新しいツールをもう一つ覚えるより良い場合は多いものです。

[Network] HTTP Keep-Alive VS TCP Keep-Alive 제대로 알기

  • ブログ · 著者: 사바라다는 차곡차곡
  • 一行要約: 名前が同じでいつも混ざる二つの概念を層と目的で分けて説明し、ヘッダーとカーネル設定とパケットキャプチャで確認します。
  • こんな人に: コネクションが切れる問題を調べていて、どちらの設定をいじるべきか迷ったことのある人。

二つの機能は名前だけが同じで、層も目的も違います。この記事はHTTP側が同じ接続で複数のリクエストを送るためのもので、TCP側はOSが周期的に接続の生存を確認するものだ、という区分を先に立てます。その上にLinuxのカーネルパラメータとWiresharkのキャプチャを重ねて、言葉だけで終わらないようにしています。コネクションプールの問題を調べるとき、この区分ができていないと見当違いの設定を何時間もいじることになります。

[Server] CLI를 위한 2가지 인증 방식, Authorization Code Flow와 Device Authorization Flow

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: CLI環境で使える二つのOAuthフローを比較し、なぜヘッドレス環境では後者が推奨されるのかを説明します。
  • こんな人に: 社内ツールにログインを付けなければならず、ブラウザのないサーバーでも動く必要がある人。

ポートバインディングとローカルブラウザ依存という具体的な制約から出発するので、二つのフローの違いが理論ではなく選択基準として読めます。PKCEがなぜ必要かも攻撃シナリオとともに押さえます。シーケンス図が付いているので、実装前に全体の流れを頭に入れるのに向いています。最近は社内CLIツールが増えている流れのなかで、実用度の高いテーマです。

로컬에서도 프로덕션과 유사한 환경에서 테스트할 수 없을까? : Testcontainers 도입기

  • ブログ · 著者: Tecoble (Woowacourse) · 5기_리오
  • 一行要約: ローカルテストはH2、本番はMySQLという不一致をどう縮めていったかを段階ごとに記録した導入記です。
  • こんな人に: ローカルでは通るのにデプロイすると壊れるテストのせいで、信頼を失ったことのある人。

企業所属のブログでありながらこれを入れた理由は、このテーマについて韓国語で書かれた導入過程の記録のなかで、段階がもっとも正直に残っているからです。最初からTestcontainersへ行ったのではなく、マイグレーションファイルを分ける中間段階を経ていて、その段階がなぜ足りなかったかが書かれています。結論だけの記事より、こうした軌跡の残った記事のほうが自分の状況へ移しやすいものです。Dockerが必要だというコストにも触れているので、判断に必要な情報が一方に偏りません。

このブログの関連記事とツール

シリーズの他の記事

Discuss on Twitter • View on GitHub