ソフトウェアエンジニア,カン・デミョン_강대명 カリキュラムの説明
ソフトウェアエンジニア
カン・デミョン

Redisの実習で学ぶ大容量サービスのための
バックエンド設計ガイドライン
「KakaoやNAVERといったIT大手企業はどうやって10万人、100万人の膨大な数のユーザーに障害なく安定したサービスを提供できるのだろう」と気になったことはありませんか?
大容量サービスがうまく構築されている大手企業でないと大容量サービスの構築方法を学べる機関は他にありません。
今回の講座では、私がNAVERでNAVER Mailを開発し、KakaoでKakaoStoryを開発して積み重ねてきたノウハウを全て公開します。

* スケーラビリティ:サーバーの追加・削除が発生した場合は、それに合わせてサービスのパフォーマンスを向上させる必要があります。バックエンドエッセンシャル必須概念を知りたいならクリック!
* レジリエント:サービスのAPIサーバー、DBサーバーなどの一部に障害が発生しても、サービスは継続的に提供されなければなりません。
* オートメーション:サービスのデプロイやサーバーの追加・削除などが、マニュアルではなくスクリプトなどによって自動化されなければなりません。
* モニタリング:サービスが正常に動作しているか把握する非常に重要な作業です。
* ngrinder:サービスがどの程度の負荷に耐えることができるのか、どこがボトルネックになるのかを知ることが重要です。ngrinderは負荷テストのためのツールです。
* prometheus:exporterを使用してそのサービスの指標を収集し、それをprometheusが保存して表示します。
* Grafana:Prometheusを通じて収集された指標を視覚化するために使用されます。
* サーバー側のロードバランシング:サーバー側ロードバランシングは、クライアントが実際のサービスを行うフロントエンドのロードバランサーだけをターゲットにし、発生した負荷はロードバランサーが自動的にバックエンドのサービスサーバーに分ける方法です。
* クライアント側のロードバランシング:クライアント側のロードバランシングは、クライアントが実際のサービスホストのリストを知り、それにより直接負荷を調整する方法です。
* サービス検出ツールZookeeper:サービスの種類とサービスに属するサーバーのリストを管理し、それを検出する方法です。
* サーキットブレーカー:外部サービスに障害が発生し、この呼び出しによって応答が遅くなった場合に、迅速に失敗させる方法です。
* レプリケーション:データの複製を意味します。サービスの可用性のためにレプリケーションは必須です。
* フェイルオーバー:サーバーに障害が発生した場合、それを置き換える別のサーバーにサービスを引き渡すことです。可用性のためにフェイルオーバーは必須です。
* コンシステントハッシュ法:大規模サービスでは、キャッシュのデータ損失もサービス応答に影響を与える可能性があります。キャッシュサーバーが追加・削除される度にデータが消える可能性がありますが、これを最小限に抑えるのがコンシステントハッシュ法です。
* インデックスシャーディング:多量のデータを分離して保存する方法です。インデックス方式は複雑ですが、各データごとにどのサーバーに割り当てるべきかを指定してくれるので、データの移動を最小化できる方法です。
* レンジシャーディング:最も簡単に適用できるシャーディング方式です。キーの範囲に従ってサーバーを割り当てます。
* モジュラーシャーディング:範囲に比べてデータを均等にシャーディングできる方式です。ただ、時間が経つにつれサーバーのスケーラビリティは制限されます。
* Guid:大規模サービスでシャーディングのために唯一のキーを作成することは非常に重要です。このために効率的に唯一のキーを作成するのがGuidです。
* 非同期キュー:APIサーバーから DB にデータを直接保存すると、最終的にAPI サーバーにデータが集中し、DBサーバーに負荷がかかります。これをキューを利用して非同期処理しながら負荷を調整すれば、より安定したサービスを運用することができます。
*ブルーグリーンデプロイメント:ローリングアップデートは、デプロイとロールバックの場合、サーバーの数が増えるほど時間が延びます。これを解決するのがブルーグリーンデプロイメントです。
*カナリアリリース:ブルーグリーンでデプロイをしても、多数のサーバーに新しいバージョンがデプロイされると、バグがある時に多くのユーザーがそれを経験することになります。このために、一部だけをデプロイするのがカナリアリリースです。
* タイムアウト:外部サービスを呼び出す際にタイムアウト値を誤って設定すると、データの重複などの問題が発生する恐れがあります。これをどのように防止するかについてのコツです。
* ルックアサイドキャッシング:通常、キャッシュは、キャッシュにデータがない場合、そのデータをDBから読み取ってキャッシュを作成します。これをルックアサイドキャッシング方式といいます。
* ライトバックキャッシング:DBに書き込むとDBに負荷がかかるため、まずキャッシュに書き込んで、後で実際のデータをストレージに保存するのがライトバックキャッシング方式です。状況によっては、データ消失の恐れがあります。
* ホットキー問題:ホットキーは、多くのデータがキャッシュサーバーまたはDBサーバーのパフォーマンスの限界を超えて特定のキーに集中している場合に発生する問題です。ホットキーの解決方法には、ローカルキャッシュ、リードレプリカを利用する方法、Multi Write Read Oneなどがあります。

カン・デミョンは2016年Redisカンファレンスで
韓国人としては初めてプレゼンテーションを行い、
現在世界中のRedisコントリビューター
(*オープンソース開発プロジェクト貢献者)
のうち22位にランクされています。
本講座では、カン・デミョンと共に
大容量サービスを構築するために
必ず知っておくべきことについて、
Redis技術と一緒に学びます。
2009年から2021年まで世界中のRedisコントリビューターのうち22位にランクされたカン・デミョン (*2021年7月基準)

Facebook、NAVER、KakaoなどのIT大手や、デリバリーサービスのBaemin、通販サイトのCoopangなどのユニコーンスタートアップ企業で、ユーザーからの大規模なメッセージを処理するために使用する分散キャッシュ技術です。
Redisは、速い速度と同時にエンジニアが簡単に使用できるデータ構造を提供し、作業効率の向上を手伝います。
Redisとは何で、なぜ重要なのか?詳細はここをクリック!

講座情報
本数:39本の映像
難易度:中級
無期限視聴

使用プログラム
- Linux or Mac
- Python 3(3.8.6)
- Ansible
- Terraform
- AWSアカウント、Access Key
※詳細はページ内下段の使用プログラムについての案内をご確認ください

動画情報
オンラインVOD
オーディオ:韓国語
字幕:日本語
この講座のポイント
「Multi-Write Read One」方式によるRedis実習映像を確認する時間を設けます。
ホットキーが発生すると、いくらパフォーマンスの良いキャッシュサーバーでも結局そのサーバーの限界以上は受け取ることができません。
このような部分を処理するために一部のキャッシュを使い、ランダムにデータを読み取るMulti-Write、Read One方式を使って問題を解決できるという事実をご存知でしたか?

問題解決の手順を理解し、実習を通してホットキーの処理方法を学びます。
大規模サービスでは、キャッシュが提供できるパフォーマンスよりも多くのアクセスが発生するホットキー問題により、パフォーマンスが低下する恐れがあります。パフォーマンスが低下しないようにホットキーを処理する方法を実習を通して学びます。

講座内容
下記のような内容を
学べます。
-
スケーラビリティ
パフォーマンスが向上できるように、サービスの拡張が可能でなければなりません。
-
レジリエント
障害が発生しても自動的にサービスが継続されるようにする必要があります。
-
オートメーション
ボタンをクリックしてサービスが自動的に復旧できるようにする必要があります。
-
モニタリング
サービスがうまく作動しているか常にモニタリングする必要があります。
-
Practice 1. サービス検出
(#スケーラビリティ #レジリエント #オートメーション)呼び出し先の追加・削除を繰り返しながら、呼び出し元がそれを自動的に認識して処理するのを確認することができます。
このような実習を通じて、サービス検出を利用することで サーバーが追加・削除された時に設定を別に変更せず、それを呼び出す側から 自動的に反映する方法を学ぶことができます。 -
Practice 2. コンシステントハッシュ法
(#レジリエント)キャッシュで動作するRedisサーバーを追加・削除する実習により、コンシステントハッシュ法でデータ配分が最小限になることを直接確認することができます。
大規模サービスでは、キャッシュデータであっても大量に消えてしまうとパフォーマンスを低下させます。コンシステントハッシュ法を利用することにより、キャッシュサーバーが追加・削除されてもキャッシュデータの消失現象が少なくなることを実際に確認し、今後これを適用できるようになります。
-
Practice 3. オートメーションansibleとterraformを使い簡単なgeoipサービスを起動する過程をお見せします。1台のawsを作成してgeoipサーバーをデプロイします。
この実習を通じて、インフラを構築する時に手動で構築するのではなく、IaC(Infrastructure as Code)を通じて常に同じ インフラを「自動化」して 簡単に構築してデプロイできることが分かります。 大規模サービスを構築するには、IaCの学習が不可欠です。 -
Practice 4. モニタリング基本的なノードに対するモニタリングを行うgrafanaダッシュボードを申請し、簡単なgeoipをデプロイし、これに対する結果を簡単に prometheusを通じてモニタリングします。
この実習を通じて、定められた数値以上のエラーが発生した場合、Slackでアラームを使って通知ができます。障害が発生したことを知るためにはモニタリングが必須です。講座でどのような情報をモニタリングすべきかを詳しく学んでください。
※カン・デミョンの講座でより詳しい内容を確認することができます。
カン・デミョン
ソフトウェアエンジニア
こんにちは、
ソフトウェアエンジニアの
カン・デミョンです。
障害はいつでも、どこでも発生します。
そのため、サービスで
障害が発生しないようにするのではなく
障害が発生した時に障害の原因を
迅速に見つけられるようにし、
その障害から早く復旧させることが
カギとなります。
大規模サービスの開発は結局
どのようにサービスを容易に拡張し
障害に簡単に対応できる構造を
作るかによってその結果が変わります。
ただし、開発ツールを学習するだけで
簡単にそれができるわけではありません。
今回の講座では、
大規模サービスの開発に必要な基本知識と
実際のパフォーマンスに影響を与える部分を
実演でお見せしながら理解を深め、
実務に活用できるようにお手伝いします。


カン・デミョン
【履歴】
・2021
- Lemontree / Software Engineer
- Tech Lead Managing AWS Infra サービスアーキテクチャ設計・構築
・2020 ~ 2021
- Weverse Company / Software Engineer
- Data Pipeline管理
(EMR, Databricks, Snowflake, Structured Streaming, Kafka)
- Airflow管理・DAG開発(k8s)
- Databricks DeltaLakeによるChanged Data Capture処理
- BIサービスのためのBackend APIのデザイン・サーバー構築
・2017 ~ 2020
- Udemy / Software Engineer
- Data Pipeline管理
- Data Pipeline OnPremise to AWS移転
- GDPR関連処理
・2013 ~ 2017
- Kakao / Software Engineer
- KakaoStory開発
- KakaoHome開発
・2008 ~ 2012
- NAVER / Software Engineer
- NAVER Mail開発
- NAVERウィンドウズモバイルアプリ開発
・2002 ~ 2008
- Final Data / Software Engineer
- Final Forensics開発
【経歴】
(著書)
・2002 ~ 2008
- Redis運用管理(Hanbit Media)
- 大容量サーバー構築のためのMemcachedとRedis(Hanbit Media)
- ウィンドウネットワークプログラミング(Daelim)
[講演]
・2019 ~ 2020
- 釜山大学SW教育センター
- DevGround Junior
- 優雅なRedis(優雅な兄弟たち)
- 安東大学公開SW体験キャンプ
- 在職者公開SW国内教育
- Netmarble
- 慶北大学
・2017 ~ 2018
- ソウル科学技術大学
- KOSSCON
- Kakao
- SW Maestro
- Zoom Internet
- Hanium
・2013 ~ 2016
- Redis Conf 2016(San Fransico)
- NHN
- Hanium
- NAVER D2SF
- 公開SW Day
- Deview 2013
- NDC 2013
一回の購入で、期限の制限なく視聴することができます。
毎週金曜日の18時、販売価格が上がります。
もうすぐ販売価格が上がる予定です。
今すぐご購入ください!

カリキュラム
カリキュラム内容の
ご紹介
インタビュー
ソフトウェアエンジニアの
カン・デミョンが
お話したいこと

世界的なエンターテインメント企業Weverse Companyでグローバル顧客向けの開発プロジェクトに参加しています
Weverse Companyでアーティストとファンとのコミュニケーション、コンテンツ、サービスを提供するグローバルコミュニティ&サービスプラットフォームであるWeverseとWeverse shopのデータを収集・処理し、データアナリストの方々がうまく分析できるようにデータパイプラインを構築する仕事をしています。ログを通じて、ユーザーがWeverseとWeverse shopにどれくらいアクセスしているか、どのような行動をとるかについての情報を安定的に処理できるようにしています。
NAVERでMobile AppとMail、KakaoでKakaoHomeとKakaoStoryなどの開発プロジェクトに参加しました
NAVERやKakaoでも多くのキャッシュサーバーを試してみることができました。3TBを超えるメモリサイズのMemcachedサーバーと、5TBを超えるRedisサーバーを扱ってみました。「走る列車の車輪を入れ替える作業」ともいわれる、DAUが1,000万以上のサービスをRubyからJavaに移行する作業もしてみました。大規模サービスにおいては問題をうまく解決することも重要ですが、簡単な部分から難しい部分まで自動化できる部分はできるだけ自動化し、モニタリングできる部分はできるだけモニタリングしてこそ快適な運用が可能であることを実感することができました。
エンジニア歴20年以上、毎日新しいシステム障害と戦っています
MAUが1,000万以上のサービスでは一日にも数台のサーバーから原因不明の障害が発生しています。32ビットカーネルでRAMディスクを使用するとなぜカーネルメモリが不足するのか、サーバーが実行される時に特定のポート帯域でクラッシュが発生するのかを、実際のLinuxカーネルソースを通じて問題を見つけて解決できた障害もあり、DNSでのキャッシングイシューによる問題、Java1.7から1.8にバージョンアップしたことで内部的に発生したイシューによる問題、米国の東部・西部間のレイテンシ問題や韓国内の地域間のレイテンシのために発生する問題なども経験してみました。Udemy社ではOnPremsisをAWSに移行する過程で多くの問題に遭遇しました。
コントリビューターや執筆活動など、Redisの様々な経験や実績があります
現在、Webサービスをはじめとする様々なSNSサービスで大容量サービスが増加しており、これにより大量データ処理技術への関心が高まっています。サーバーを分散させ、多くのトラフィックに耐えられる分散キャッシュ技術は、大容量サーバーを構築するための重要な役割を果たすからです。だからRedisは、バックエンドエンジニアの強い味方になれます。この講座を通して、多くのバックエンドエンジニアが容易に作業できるようにサポートしたいと思います。
どのような方々にこの講座をお勧めし、受講することで何が得られますか?
バックエンドエンジニアとして就活中の方や1~5年経歴のジュニアエンジニアに最も役に立つと思います。詳しく言うと、初心者にはSection 1、ジュニアには実際の大規模サービスに関する知識が得られるSection 2が良いかと思います。実務経験があれば、実務での様々な問題を取り上げているSection 3を中心に見ると良いでしょう。 受講する前は、背景知識として「バックエンド」について理解しておくと良いでしょう。簡単なWebサービスを開発した経験があればもっと理解しやすい講座となっています。この講座を受講することで、大規模サービスを構築するために知っておくべきことについて確実に身につけることができると思います。
使用プログラムについて
ご案内します。
当講座は、以下のツールを使用します。
[メインツール]
- Linux or Mac
- Python 3(3.8.6)
- Ansible
- Terraform
- AWSアカウント、Access Key
※MacとWindowsの受講の可否に関しては、本講座はWindows(Windows10、64-bit OS)で撮影しましたが、実際の実習はMacやLinuxで動作しています。
(リモートでLinuxサーバーを起動し、そこで動作することをお見せする予定)
※実習中にAWSサーバーを起動する部分がありますが、この実習のためにはAWSアカウント作成が必要し、AWSの料金が発生します。ただし、ほとんどの実習はローカルで行うことができるようになっています。(いくつかの実習に限り、AWSの使用必須)

おすすめの講座
この講座を見た方は
こちらもチェック!
返金規定
Coloso返金規約
Colosoサービスを利用される利用者様((以下、「会員」とする。)が、株式会社Day1Company(以下、「弊社」とする。)にてご購入された講座チケットの返金、返品・交換について、各々次の規定に沿って対応いたします。また、弊社が別途定めた返金、返品・交換について規定がある場合、その該当の規定に沿うものとします。
購入と同時に受講が可能な講座について:受講有無に関係なくキャンセル不可
事前予約講座について:
①購入後、映像公開前まではキャンセル可能
②映像公開後はいかなる場合でもキャンセル不可
動画再生端末の台数制限について
1つのアカウント当たり再生可能なデバイス数は3台でございます。デバイスの登録は、動画視聴時に順次登録されることになります。携帯の機種変更などの理由で、登録されたデバイスを削除されたい場合は、help@coloso.jpまでお問い合わせください。年1回に限りデバイス変更が可能になります。
(3つ目のデバイスまでは動画を再生すると自動で登録されます。)