デカップリングとはなに？ |
 |
 |
デカップリング（decoupling）は、簡単にいうと ITでは特によく使われます。 例えば、システムAがシステムBを直接呼び出していて、
みたいな状態は「密結合（tight coupling）」です。 これを避けて、
ようにするのがデカップリングです。 具体例キューを挟むよくあるのがメッセージキューです。 悪い例： メールサーバが重いと、Web側も遅くなる。 デカップリング後： こうすると：
になります。 なぜ重要？大規模システムほど、 なので、
などで依存を弱めます。 ただし万能ではないデカップリングすると、
というデメリットもあります。 例えばQueueを挟むと、 なので実務では、 IT以外でも使う実は一般概念としても使われます。 例えば会社組織でも：
みたいなのも広い意味ではデカップリングです。 つまり本質は、 |
 |
|
証跡情報とは？ |
 |  |
証跡情報（しょうせきじょうほう）とは証跡情報とは、**「誰が、いつ、何をしたかを後から確認できる記録」**のことです。 英語では Audit Trail（監査証跡）や Log（ログ）と呼ばれることが多いです。 例えば、
といった情報が証跡になります。 なぜ必要なのか障害調査例えばサーバーが停止した場合、 という証跡があれば原因を追跡できます。 不正アクセス調査例えば、 という記録が残っていれば、不正アクセスの可能性を調査できます。 内部不正対策例えば顧客データが消えた場合、 という証跡が残っていれば、何が起きたのか確認できます。 良い証跡の条件一般的に、
が記録されていることが望ましいです。 例えば、 のような形です。 ログとの違い厳密には少し違います。 ログシステムが出力する記録全般 例： 証跡監査や追跡のための記録 例： つまり、 証跡はログの一種だが、特に「人やシステムの行動履歴」に重点を置いたもの 一言でいうと証跡情報とは、 「後から『何が起きたのか』を証明するために残しておく記録」 です。システム運用、セキュリティ監査、内部統制の世界では非常に重要な情報として扱われます。 |
 |
 |
EMRクラスターとは何？ どんなことに使うの？ |
 |  |
EMRクラスターは、簡単に言うと
です。 AWS の EMR（Elastic MapReduce）は、
などの分散処理基盤を、AWS上で簡単に動かすサービスです。 1. 「クラスター」とは何かまずクラスターとは：
です。 EMRでは、
ものEC2をまとめて、
できます。 2. なぜ必要なのか普通の1台のサーバでは：
などが重すぎる。 そこで、
します。 3. EMRで何をするのか代表例を挙げます。 ① ログ分析例えば：
を集め、
する。 Spark がよく使われます。 ② ETL（データ加工）大量データを：
する。 例：
③ 機械学習前処理MLでは前処理が非常に重い。
を分散実行。 ④ データレイク分析S3上の巨大データを：
する。 Hive や Spark SQL が使われる。 4. EMR の内部構造（ざっくり）EMRクラスターには通常： (1) マスターノード
(2) コアノード
(3) タスクノード（任意）
5. Hadoop / Spark との関係ここが重要です。 EMR は：
です。 つまり：
6. なぜ「Elastic」なのか必要に応じて：
ができるからです。 例えば：
みたいに調整可能。 これがクラウドとの相性が良い。 7. なぜ「MapReduce」という名前なのか元々 Hadoop の中心技術だった：
という分散処理モデル由来です。 ただ現在は、 8. EMR のメリット(1) 分散処理基盤を自前構築しなくていい本来かなり面倒：
をAWS側がかなり吸収。 (2) S3と相性が良い巨大データをS3に置き、 (3) 一時利用が可能処理後にクラスター削除可能。 9. EMR が向かないケース逆に：
にはオーバースペック。 10. 一言でイメージすると普通のサーバが：
なら、 EMRクラスターは：
感じです。 まとめEMRクラスターとは：
主用途：
本質は：
です。 |
 |
 |
ステートレスとは何？ メリットとデメリットを教えて |
 |
|
**ステートレス（stateless）**は、 例えばHTTPは基本的にステートレスで、リクエストごとに 対になるのがステートフルで、こちらはサーバが イメージステートレス： ステートフル： メリット一番大きいのはスケールしやすさとシンプルさです。 ・サーバが状態を持たない → どのサーバでも同じ処理ができる ・障害に強い ・実装がシンプル ・キャッシュと相性がいい デメリット代わりに毎回のリクエストが重くなりがちです。 ・必要な情報を毎回送る必要がある ・クライアント側に負担が寄る ・複雑な処理に向かない場合がある ・セキュリティ設計が重要 実務的な落としどころ完全なステートレスは理想ですが、実際はこうなりがちです： ・認証 → JWTなどで擬似的にステートレス化 つまり まとめステートレスは、 API設計やマイクロサービスではほぼ前提になる考え方なので、かなり重要な概念です。 |
 |
|
Kinesis Client Libraryって、ただでさえ複雑なKinesis系のサービスの何をよりよくするの？ |
 |  |
Kinesis Client Library（KCL）は、 「Kinesis Data Streams のコンシューマを楽に作るためのライブラリ」 です。 Kinesis自体が複雑というより、シャードを複数台で並列処理し始めると急に面倒になるので、その面倒を肩代わりしてくれます。 KCLがない場合例えば4シャードあるとします。 EC2を2台で処理したい。 すると自前で、
を実装する必要があります。 結構大変です。 KCLがやることシャードの割り当て例えば： を自動管理。 Worker Aが落ちたら、 みたいに引き継ぐ。 チェックポイント管理「どこまで読んだか」を保存します。 オンプレでいうと、 みたいなものです。 再起動後も続きから読める。 負荷分散ワーカーが増減しても、 シャードの担当を再配置してくれます。 シャード再編への追従Kinesisではシャードを増減できます。 例えば： のような分割。 KCLはこれもある程度吸収してくれます。 オンプレで例えると感覚的には、 をまとめたようなものです。 なぜAWS試験で出る？試験では、
という問題が出ます。 そのとき、 が正解候補になります。 なぜなら、 分散処理の面倒な部分を自動化してくれるからです。 一言でいうとKCLは、 「Kinesis Data Streams のシャード管理・負荷分散・読取位置管理を肩代わりしてくれるライブラリ」 です。 Kinesisを簡単にするというより、 「Kinesisを複数台で安全に運用する難しさ」を解決するための道具と考えると理解しやすいです。 |
 |
|
Queue とはなに？ |
 |
|
Queue（キュー）は、簡単に言うと コンピュータでは、 基本動作キューは普通、
をします。 つまり： FIFO（First In, First Out） です。 イメージ例えばコンビニのレジ。
これがキューです。 なぜ必要なのか一番大きい理由は： 「処理を分離して安定化するため」 です。 例：Webサービス例えばECサイトで：
を全部リアルタイムでやると重いです。 そこで：
にします。 すると：
ができます。 よくある用途非同期処理王道。
など。 バースト吸収アクセス急増時に：
できます。 システム疎結合化送信側は： 「キューに入れた」 だけで終わり。 受信側を知らなくていい。 リトライ失敗したら：
など。 よく使われる製品代表的には：
など。 ただし厳密には、 Queue と Stack の違い混同しやすいです。 Queue： Stack： 実務で超重要な考え方Queueの本質は： 「今すぐやらなくていい仕事を切り離す」 です。 これで：
デメリットもちろんあります。 即時性が下がる非同期になるので、 順序問題複数ワーカーで順番が崩れることがある。 重複処理再送で同じ処理を複数回やる場合がある。 → 冪等性が重要。 まとめQueueは、 「処理を一旦並べて、あとで順番に実行する仕組み」 です。 現代システムでは：
の中心になるかなり重要な概念です。 |
|
|
結果整合性について説明して下さい。 |
|  |
結果整合性（Eventual Consistency）は、 という考え方です。 例3台のDBノードがあるとします。 で、 を： へ更新。 でも分散システムでは即座に全台同期できないことがあります。 その瞬間：
みたいになる。 つまりアクセス先によって： が返る可能性がある。 でも少し待てば： になる。 これが結果整合性。 なぜこんなことをするの？強整合性（常に完全一致）をやると：
からです。 特にクラウドの巨大分散システムでは： な場面が多い。 よく使われる場所
など。 イメージ強整合性結果整合性です。 ただし「いつ一致するか」は保証弱め重要なのは： 数秒〜十数秒ズレることもある。 AWSでの例昔のS3は： がありました。 現在のS3はかなり強整合性寄りに改善されています。 一方DynamoDBなどは、
を選べることがあります。 結果整合性の方が：
ためです。 |
|
|
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
にほんブログ村
