TCP/IPを理解する
クラウド、データ分析の熱が落ち着いて、「基本的なITの知識を知ろう」のターンが回ってきました。
となると、手を出すのはネットワークですよね。
積読になっているこの本を読んで、ざっくり理解したので記事にします。
TCP/IPとは何か?
「TCP/IP」という言葉は2つの意味を持ちます。
そもそもプロトコルとは、コンピュータ同士で通信する際の手順や規格、つまりは約束事のこと。
IPやTCPというプロトコルがある(そもそもIPもTCPも最後のPはProtocol)一方で、それらはインターネットにおいて代表的なプロトコルであったため、それらに関係あるプロトコル群も含めてTCP/IPと呼ぶようになったようです。
例えるなら、マクドナルドの「ハンバーガー」ですかね。
メニューとしてのハンバーガーもあれば、バーガー系を総称してハンバーガーとも呼ぶ。そういうノリでしょうか。
ちなみに、2つ目の意味で言ったときに含まれるほかのプロトコルは、以下のようなものがあります。
なぜTCP/IPは普及したのか?
今では一般的に使われているTCP/IPですが、数あるプロトコルの中でなぜこれが爆発的に普及したのでしょうか。
それは、この2つが大きな原因でした。
パケット通信に対するモチベ
1960年代の軍事技術が始まりでした。軍事的に、戦場の人々に作戦を伝えるための通信は非常に重要です。
さらに、通信ルートを誰かが壊しても、別ルートで通信できること(今でいう可用性)が非常に重要でした。
確かに、それが自分の生死に関わるとなれば必死に研究しますよね。
またその後、軍事利用でなくとも、回線コストを下げる目的でも活発に研究されたそうです。
パケット通信ができれば、複数のユーザーが1つの回線を共有できます。これができないと、それぞれのユーザがそれぞれ専用線を引かないとやり取りできません。
さて、このようなモチベーションから、なんやかんやあって1975年にTCP/IPは誕生しました。誕生してからも具体的な仕様は検討が続き、結局1982年にTCP/IPの仕様が決まりました。
このとき、TCP/IPを生み出したのは大学や研究機関でした。同じくこのころ、大学や研究機関が開発して利用していたもの…それはUNIXというOSです。
そのため、UNIXにはTCP/IPが実装されるようになりました。これが、次の理由につながります。
UNIXの普及
1980年代は、各企業を中心にUNIXマシンをつなげてやり取りすることが広まっていった時代です。
そのUNIXにはTCP/IPが実装されているので、ネットワーク構築にはこのTCP/IPを利用するのが自然ですよね。
このようにして、TCP/IPはUNIXとともに普及していったのでした。
ちなみに、このころ(1980年代)からTCP/IPによる世界的なネットワークをインターネットと呼ぶようになりました。
その後は、1990年代に入って一般家庭にもインターネットが普及していきます。利用者数は爆増しましたが、TCP/IPは研究ネットワークとして長い間運用され磨き上げられていたおかげで、利用することができています。
IPの具体的な約束事とは?
大きくは以下の3つです。
- IPアドレスというアドレスを用いる
- 経路制御(ルーティング)でパケットを終点ホストまで届ける
- IPパケットは分割、再構築する
IPアドレスというアドレスを用いる
これは、馴染みのある言葉だと思います。ネットワーク層であるIPでは、IPアドレスを用いて通信します。
IPアドレスの形式は、ホスト利用するデータリンクの種類によらず、同じ形式です。
(データリンク:ネットワーク層より1つ下の層。現在はイーサネットが主流)
今後、別のデータリンクが出てきても関係なくIPアドレスは利用できます。つまり、うまく抽象化ができているということです。
経路制御(ルーティング)でパケットを終点ホストまで届ける
この仕組みを使うことで、自宅から地球の裏側のブラジルのサーバまでパケット通信ができます。
そもそも、インターネットは全世界にあるたくさんのルータをバケツリレーのようにして通信しています。
そのルータは膨大な量あり、かつどんどん変化します。なので、最初から「ブラジルまでのルートは、ルータA→ルータB→…」と決められません。
そのため、ルーターごとにルーティングテーブルという表を持たせておきます。
ルーティングテーブルとは、「最終地点がxxであれば、次はルーターXに飛ぶ」という対応表です。
パケット通信をする際は、各ルーターのルーティングテーブルを見て、次はどのルーターに飛ぶかを適宜判断して、進んでいくのです。
IPパケットは分割、再構築する
パケット通信に利用するデータリンクには、最大転送単位(MTU)というのが定められています。
つまり、送信する際の最大の容量が決まっているということです。パケットがそれより大きいと、本来は送れません。
そこで、ルーターでパケットを分割して送り、最後に受信したホストが再構築して元通りにします。
ちなみに、ルーターは分割だけして、再構築は行いません。
ただ、できれば分割はしたくないのが本音です。分割すると、そのうちの1つでもかければ復元できないからです。
そのため、できるだけMTUに引っかからないギリギリの大きさで送りたい。そのギリギリの大きさを特定するために、経路MTU探索という技術が使われています。
これは、最近では多くのOSで利用されています。
TCPの具体的な約束事とは?
大きくは以下の5つです。
TCPについては少し細かいので、それぞれの内容の説明はここには書きません。
ただ、IPがとにかく相手ホストへ届けるための約束事だったのに対して、TCPはきちんと届けるための約束事である、という点が重要です。
- ポート番号という番号を用いる
- 途中でパケットが喪失した場合再送させる
- 分割されたパケットの順序を制御する
- 通信相手がいるかどうかコネクションを制御する
- ネットワークが混雑しないようにパケットの送信料を調整する
TCPとUDPの違いは?
どちらもトランスポート層のプロトコルですが、一長一短があります。
そのため、利用目的に応じて使い分ける必要があります。
一言でいうと、TCPは信頼性のある通信を提供し、UDPは信頼性よりも速い通信を提供します。
この違いは、人と人とが対話するIP電話やテレビ電話を使うとわかりやすいです。
TCPはコネクション型(相手の応答を待ってから通信開始する)で、かつデータが途中で失われたときに再送処理を行ってくれます。
IP電話に利用すると、音声の再生がスムーズにいかず遅れが生じたりします。その代わり、音声品質は高いです。
UDPはコネクションレス型(相手の応答確認せず通信開始する)で、再送など細かい処理はアプリケーションが担います。
IP電話に利用すると、多少パケットが失われて音声が乱れる場合がありますが、遅延は起こらず会話ができます。
このように、IP電話やテレビ電話といったリアルタイム性を重視する場合はUDPが適しています。
逆に、youtubeの動画再生など数秒遅延しても良い場合は、TCPが適しています。
所感
なんとなくTCP/IPやインターネット、イーサネットなどの言葉を使っていましたが、だいぶ理解が進みました。
特に「プロトコル」というのがずっとふわふわしていましたが、利用するアドレスの種類やヘッダフォーマット、再送やコネクションの確認方法など約束事の集合体だと理解すれば腑に落ちました。
また、初期のころ別々の規格で作っていて通信できなかった→標準化で楽にできるようになった、という流れのところは、データのサイロ化にも適用できないかな?と思いました。
今は、データがDBに入っていたりストレージに入っているという違いや、csv、parquet、ただのファイルといった違いでうまくやり取りできていません。
これらをETLなどで処理していますが、標準化することでスムーズに流通させられないものか…。これがSnowflakeの目指している世界なのかもしれません。
あとは、TCPとUDPの違いは分かりやすく説明されていたかなと思いました。具体的なIP電話の例は分かりやすい。
ただ、たまに(特にgoogleのmeet?)音声は聞こえるけど10秒くらい遅延しているときがあるように思います。
この時は、TCPを使ってしまっているのか?などちょっと気になりました。
以上、私の理解まとめになります。細かいところは本を読んでチェックや!
HBase触ってみた
皆さんこんばんは。花粉が舞いに舞っている昨今、いかがお過ごしでしょうか。 春といえば、OSSのDBが恋しくなります。ということで、HBaseを今日一日触っていたので、その記録を書こうかと思います。
というのも、オライリーのデータ指向アプリケーションデザインの第6章「パーティション」を読んでいて、実際にプロダクトを触りたくなってきたからです。
データを分散して分けた1つ1つをパーティションと呼び、それをどのように分けるか?はたまたどのようにリバランシングするか?
などが載っていました。概念は理解しましたが、実際に実装だとどういう感じなのか理解したかった次第です。
HBaseとは?
- ApacheのOSSのプロダクトのうちの1つ。
- HDFS(Hadoop Distributed File System)上に構築するデータベース。
- HDFSは、Hadoopに使われる分散ファイルシステム。いい感じに分散してファイルを保存する。
- NoSQLの中のワイドカラム型に属する。
- キーバリュー型の拡張。1つのキーに対して複数の列を持つことができる。
- Regionという単位でデータを分散して持つ。そしてそのRegionをスレーブノードに割り当てる。
- スレーブノードは他のPC1台に当たる。つまり、PC1台を追加する(スレーブノードを追加する)と、Regionが新たに割り当てられてスケールアップする。
HBaseの概要とアーキテクチャ | Think IT(シンクイット)
ここを読めばかなり詳しくわかります。
いわゆるMPP(Massively Parallel Processing)はRDBMSが並列処理を可能にしたものだけど、それとはまた別流派の分散DBといった感じでしょうか。
とにかく、パーティションを実現できるOSSなので、HBaseを今回は触ってみたいと思います。
HBaseのインストール
環境
Windows10
Docker version 20.10.5
docker-compose version 1.29.0
上記のWindows端末で実行していきます。
DockerでHBaseのコンテナ作成
① 資材をcloneしてくる
GitHub - big-data-europe/docker-hbase
上記のリポジトリをcloneしてきましょう。
Windowsでのgitのインストールはここなど詳しいです。
【Windows】Gitの環境構築をしよう! | プログラミングの入門なら基礎から学べるProgate[プロゲート]
ちなみに、以下の2つがdocker-composeファイルです。
今回は、分散処理させてみたかったので「distributed-local」の方を使います。
・docker-compose-distributed-local.yml
・docker-compose-standalone.yml
② ビルド実行
cloneした場所にPowerShellで移動して、以下を実行します。
docker-compose -f docker-compose-distributed-local.yml up -d
これでymlファイルに記載されているコンテナが複数ビルドされ、さらに立ち上がるはずです。
私はこれとは別にDocker Desktopも入れていますが、それ上ではこのように見えています。
③ WEB UIで確認
http://localhost:16010
にアクセスしてみましょう。
上手くHBaseが立ち上がっていれば、以下のような画面になります。
(テーブルやRegion数はいじった後なので、立ち上げ直後とは異なると思います)
参考
以下のページを参考にしました。
docker composeを使って「hbase」を構築するまでの手順 | mebee
HBaseのインストールと実行方法(スタンドアロンモード) - TASK NOTES
HBaseでのテーブル作成
テーブル作成、データ挿入
① コンテナログイン
マスターノードにログインします。「hbase-master」がマスターノードのクラスター名です。
docker exec -it hbase-master /bin/bash
② hbase-shell起動
(ここからはマスターノード上でコマンド実行します)
ログイン出来たら、以下のコマンドで対話型のコマンドラインツールを起動します。
hbase shell
次からは、このツール上でhbaseに色々なコマンドを打っていきます。
③ テーブル作成
create文でテーブルを作成します。
create 'テーブル名', 'ColumnFamily名' です。
create 'test_table', 'cf'
④ テーブル確認
WEB UI上で確認します。
以下のように、新しいテーブルができていれば成功です。
このテーブルは、Online Regionsがまだ1なので、分散されていない状態ですね。
⑤ データ挿入
put文でデータを挿入します。
put 'キー名', 'ColumnFamily名:Column名', 'バリュー' です。
put 'test_table', 'row1', 'cf:col1', 'value1'
このあたりの関係性は、以下のページが分かりやすいです。
HBaseのアーキテクチャを理解しよう (1/3):CodeZine(コードジン)
⑥ データ確認
WEB UI上で、Tableをクリックすると以下の画面に遷移します。
赤枠で囲っている、Requestsが1になっていればデータが挿入されています。
(「scan 'table名'」をhbase shellで打っても、データの内容は確認可能です)
HBaseでのパーティション確認
さて、ここからが本題。パーティションです。
事前パーティション
① 事前パーティションを定義してテーブル作成
以下のコマンドで、新しいテーブルを作成します。
今度は、キーの範囲でパーティションを切るように指定しています。
create 'test_table2', 'cf', SPLITS => ['1000','2000','3000','4000']
② 確認
WEB UIで確認します。
~1000 / 1000~2000 / 2000~3000 / 3000~4000 / 4000~
の5つのパーティションが作成されていることが分かります。
③ データを挿入
1000~2000のパーティションにデータを挿入してみます。
今回は、キーを'1234'にしてみましょう。
put 'test_table2', '1234', 'cf:col1', 'value1'
④ 確認
WEB UIで見ると、ちゃんと想定のパーティションのRequestsが1となっていますね。
パーティションの強制分割
ここでは、今5つに分けられているパーティションのうちの1つを強制的に分割してみます。
以下のページを参考にしています。(ちなみに、強制マージはできないそうです)
Apache HBase Region Splitting and Merging - Cloudera Blog
① 分割
ここでは、split文を用います。
split '8efadd362101393ea6e29e7cc7ee3fd0'
split 'encoded region name'
とすることで、指定のパーティションが分割されます。
'encoded region name'は、テーブル名とパーティションの開始の値(1000など)とtimestampのハッシュを取ってエンコードされたものだそうです。
参考:HBase hbckについて その1 - Qiita
'encoded region name'は、WEB UIだとここに表示されています。
② 確認
WEB UIで確認してみますが…
変化がないです。なぜかパーティションが分割されていませんね。
データ量が少なすぎた?少し大きいデータをいくつか挿入してみましょう。
③ データ挿入
以下のput文を、キーの値が1100, 1300, 1600, 1900の4種類ごとに10回打ちました。
100万文字は半角数字だったので、1回につき約1MBですね。
そのため、全部で40MBのデータを挿入した計算になります。
put 'test_table2', '1100', 'cf:col1', '[100万文字]'
さて、これでsplitを再度打ってみましょう。
(一応、split打つ前はこんな感じ。Requestsが44に増えてます)
④ splitと確認
前と同じsplit文を打ちます。
split '8efadd362101393ea6e29e7cc7ee3fd0'
結果はこちら。
見事に2つに分かれている…が、分割しているキーの範囲が何かおかしい?
1100, 1300, 1600, 1900に分けたので、1500くらいで分割されてくれると思いましたが。。
これは原因不明です。わかる方いたら教えてください。
自動パーティション分割
こちらは、HBaseのver0.94以降では、
Min (R2 * “hbase.hregion.memstore.flush.size”, “hbase.hregion.max.filesize”)
この式を超えると自動で分割されるそうです。
この2つは設定値で変更可能です。
・"hbase.hregion.memstore.flush.size”
・“hbase.hregion.max.filesize”
また、Rは同じテーブル内の現在のリージョンの数。
例えば、まだ1個しかリージョンが割当てられていない状態で、"hbase.hregion.memstore.flush.size”が128MBだとすると、その時は128MBを超えたら分割されます。
次は、2個割り当てられているのでRは2です。そのため、22 * 128MB=512MB を超えたら分割されます。
本当はこれを試してみたかったですが、このサイズのデータを挿入するのがかなりしんどいため見送りました。
どなたかやってみてください。
まとめ
- HbaseはOSSの分散データベース。
- docker-composeを使って簡単に構築可能。
- テーブル作成の際にパーティションを指定できる。
- splitコマンドで強制的に分割できる。
- なぜかきれいなパーティション範囲で分割できず。
- 自動分割も可能。設定値を変更すれば閾値も変えられる。
OSS知識欲が出てきたため、Sparkなども触ってみたいですね。
それでは。
入門 Avro 第2版
オライリーっぽいタイトルつけてみました。こんにちは。
最近はダラダラと過ごしてしまっていますが、今回はApache Avroをちょっと触ってみたのでその記事を書こうと思います。
Avroとは?
効率的にデータが保存できる、バイナリのフォーマットです。
いわゆる行指向フォーマットというやつで、OLTP処理の場合に向いているフォーマットとのこと。
そのあたりの全体像はこのブログが詳しかったので、ぜひ。
カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog
また、こちらの本
の中には、Avroにおいて鍵となる考え方は、ライターのスキーマとリーダーのスキーマは同一である必要がなく、互換性さえあればよいという考え方です。
とあります。
つまり、スキーマ定義(このデータは"Name”(String)、"Age"(int)という列を持っているぞ!のようなもの)がライターとリーダーで別々で持てるということです。
(互換性は持っておく必要あり)
別々で持てると、例えば「次のアプリからは今まであった"Age"ってカラムいらなくなったんだよなぁ~」というときは、リーダーのスキーマ定義だけ変更するとかの対応ができますよね。
スキーマの進化に対して、修正のハードルが低いんですよ、という内容が載っていました。
と、ここまで読んだら、実際にコード書いて確かめたくなりますよね。
というわけで、実際にpythonで書いてみました。
まずは公式チュートリアル
Apache Avro 1.11.0 Getting Started (Python)
とりあえずここに書いてある内容を読んで動かせば、avroファイルの書き込み、読み取りのイメージはつかめます。
ただ、
- コードと説明が背景同じで書かれているのでどの部分がコードなのか分かりにくい
- python3の実装と書いてあるのに、print文の書き方が2系(print("aaa")ではなく、print "aaa"になってる)
という罠があるので気を付けてください。
一応、ここからはチュートリアルの内容を見ていきます。
以下、チュートリアルのコードを私が見やすいように整形したものです。
・pythonコード
import avro.schema from avro.datafile import DataFileReader, DataFileWriter from avro.io import DatumReader, DatumWriter def avro_write(write_file, schema): writer = DataFileWriter(open(write_file, "wb"), DatumWriter(), schema) writer.append({"name": "Alyssa", "favorite_number": 256}) writer.append({"name": "Ben", "favorite_number": 7, "favorite_color": "red"}) writer.close() def avro_read(read_file): reader = DataFileReader(open(read_file, "rb"), DatumReader()) for record in reader: print(record) reader.close() write_file = "users.avro" read_file = "users.avro" schema = avro.schema.parse(open("user.avsc", "rb").read()) avro_write(write_file, schema) avro_read(read_file)
{"namespace": "example.avro", "type": "record", "name": "User", "fields": [ {"name": "name", "type": "string"}, {"name": "favorite_number", "type": ["int", "null"]}, {"name": "favorite_color", "type": ["string", "null"]} ] }
単純に、書き込みと読み込みを行っています。
このpythonファイルを実行すると、実行結果はこの2行です。
{'name': 'Alyssa', 'favorite_number': 256, 'favorite_color': None}
{'name': 'Ben', 'favorite_number': 7, 'favorite_color': 'red'}
Alyssaの"favorite_color"は、python内の書き込みで指定していないため、結果出力ではNoneになっていますね。
これは、スキーマ定義で"favorite_color"のtypeに"null"が含まれているためです。
試しにスキーマ定義の"null"を削除してみると、エラーが返ってきました。
さて、基本的な読み込み書き込みはこれで私も理解したのですが、ここで1つ疑問が。
書籍内では、リーダーとライター別々のスキーマ持てるって聞いたけど、このチュートリアルだとライターしかスキーマ定義使ってなくね?
ということです。
確かに、読み込みの時はスキーマを使わなくても読み込めています。
どうやら、読み込みの時何も指定しなくても、ライターの定義を内部で保持していて、それを勝手に使ってくれるようです。
ただ、どうせなら別々のスキーマ定義使いたい!ということでその実装方法も調べてみました。
ライターとリーダーで別々のスキーマ定義を使ってみる
まずは、使うスキーマ定義を。
v1として前使っていたものと同じスキーマ、v2としてその中の"favorite_color"を落としたものを使います。
そして、ライターではv1、リーダーではv2を使ってみます。
つまり、ライターの時はfavorite_colorが定義されているからデータとしても書き込まれているけど、
リーダーの時はfavorite_colorを無視したい!というユースケースですね。
・スキーマ定義_v1(user_v1.avsc)
{"namespace": "example.avro", "type": "record", "name": "User", "fields": [ {"name": "name", "type": "string"}, {"name": "favorite_number", "type": ["int", "null"]}, {"name": "favorite_color", "type": ["string", "null"]} ] }
・スキーマ定義_v2(user_v2.avsc)
{"namespace": "example.avro", "type": "record", "name": "User", "fields": [ {"name": "name", "type": "string"}, {"name": "favorite_number", "type": ["int", "null"]} ] }
では、使うpythonコードです。
変更点は、リーダーにもスキーマを使うようにしたところです。
そのやり方がどこにも書いてなかったので結構てこずりましたが、頼るべきものは公式。
avro/io.py at release-1.7.7 · apache/avro · GitHub
上記の実際のavroのpython実装を見ると、DatumReader()のinitにこんなものが書いてあるじゃないですか。
確かに、さっきまでの公式チュートリアルだとDatumReader() と引数なしで使っていた。
なので、リーダーのスキーマだけ指定するように
DatumReader(None, reader_schema)
という感じに使ったら、見事動きました。
以下、完成品です。
import avro.schema from avro.datafile import DataFileReader, DataFileWriter from avro.io import DatumReader, DatumWriter def avro_write(write_file, schema): writer = DataFileWriter(open(write_file, "wb"), DatumWriter(), schema) writer.append({"name": "Alyssa", "favorite_number": 256}) writer.append({"name": "Ben", "favorite_number": 7, "favorite_color": "red"}) writer.close() def avro_read(read_file, schema): # ここでリーダーのスキーマ定義を使う reader = DataFileReader(open(read_file, "rb"), DatumReader(None,schema)) for record in reader: print(record) reader.close() write_file = "users.avro" read_file = "users.avro" schema_v1 = avro.schema.parse(open("user_v1.avsc", "rb").read()) schema_v2 = avro.schema.parse(open("user_v2.avsc", "rb").read()) avro_write(write_file, schema_v1) avro_read(read_file, schema_v2)
実行結果はこちら。
{'name': 'Alyssa', 'favorite_number': 256}
{'name': 'Ben', 'favorite_number': 7}
見事、リーダーのスキーマ定義だけ落とした"favorite_color"が出力されていませんね。
これで、明日から急にAvroで別々のスキーマ定義したいといわれても対応できます。
アードベッグ10年とアードベッグコリーブレッカン飲み比べてみた
ボンジョールノ!supa25です。
今日は、私が愛してやまないアードベッグ10年と、シリーズの中でも最もスモーキーといわれるコリーブレッカンを飲み比べしてみようと思います。
この前、10年飲んでて色々調べていたら、気づいたらぽちってたのがコリーブレッカンです。
前も一度買ったことあるのですが、あの時とは感覚も違うだろうと再チャレンジしたものになります。
相変わらずジャケ写はかっこいい。
コリーブレッカンは、渦のようなアイコンが右下に見えますね。
そもそもコリーブレッカンとは、アイラ島付近に発生する渦潮の名前です。
そこからも、力強そうなのがうかがえますね。
テイスティング
色
10年は薄い。コリーブレッカン(今後、コリと呼ぶ)は濃い。琥珀色。
香り
10年は、甘さ、次に柑橘。その中に煙たさもある感じ。いわれてるみたいに、煙で臭い!よりも先に柑橘のいい香りが来る。
コリは、スパイシーさ、オイリーな海。嗅いだ直後は無臭なんだけど、そこからスパイシーさが来る。
これ、コリの方は5年のウィービースティにちょっと似てる気がする。
ストレート
10年は、とにかく口当たりよし。柑橘がきて、最後後味は煙。浅瀬な感じ。
コリは、スパイシーさ。アルコール度数高いだけあって、アルコール感あり。ずっしりくる。大陸棚って感じ。
ちょい加水
10年は、ちょっと薄め?後味がストレートと比べてライトになってる。
コリは、ちょっと飲みやすくなってるが、下のピリつきはある。
トゥワイスアップ
10年は、さわやか8割、スモーキー2割。後味は特にないけど、ぐびぐび飲めそう、おいしい。
コリは、これトゥワイス?ってくらい濃い。すごい。スパイシーさが分かりやすい。これ、コリの味をそのままわかりやすく伝えてる気がする。
ロック
10年は、落ち着いてる。しっとりしてる感じ。後味は、スモーキーと柑橘が5:5で続く。
コリは、舌ピリつく。味が濃い!重厚感ある。ただ、飲みやすいよ。
ハイボール
10年は、弾ける柑橘。スモーキーはほぼない。うますぎ。
コリは、オイリーな煙さ。しっかり味が分かる。
AWS Certified Solutions Architect – Associate に合格しました
皆さんこんばんは。もうすぐ2022年も1か月が終わりますが、いかがお過ごしでしょうか。
年始に建てた目標との乖離がそろそろ出てきた頃でしょうか。私も、最近ジム通いのペースが落ちてきているので頑張らないと。
と、いうことで、年末から勉強していたAWS Certified Solutions Architect – Associate(AWS SAA)の試験を受けてきました。
結果、803/1000で合格!となりましたので、忘れないうちにブログを更新します。
AWS SAAとは?
AWS Certified Solutions Architect – Associate 認定
AWSの資格内で、真ん中の層であるアソシエイトレベルで、かつアーキテクトとしての知識が求められる資格です。
AWSのサービスを使って、可用性/コスト効率/耐障害性が高いスケーラブルなアーキテクチャを作れるような知識が問われます。
選択問題のみ(複数選べ、もある)で、65問の問題が出ます。72%が合格ラインとなっています。
色々なブログやtwitterや周りの人の声を聴くと、まずはこのAWS SAAを取るのが王道っぽいので、これから取ってみました。
資格取ってよかったこと
広くAWS知ることができるので、業務にも影響あるメリットが多いです。
個人的に、AWSのシステム触るならまず必須で取っておくべきだと思います。
- インフラ部分のエラーなどに強くなる
私のチームでは、アプリ担当とインフラ担当が分かれています。
IAM権限の修正/付与、ネットワークの構築、バックアップや通知の設定などはインフラ担当がやってます。
このあたりでエラー起きたとき、毎回インフラ担当者に見てもらっているのですが、結構な頻度で起きているので担当者が多忙に…。
この試験では上記の基本がわかるようになるので、なんとなくエラーの原因と対応策が分かるようになります。
そのため、インフラ担当者の負担が少し減る!…かも。
- 新しくシステム構築する際に、AWSサービス王道組み合わせが分かる
こういう時はこういう組み合わせ、というのがたくさん出てくるので、なんとなくパターンが頭に入ります。
例えば、踏み台EC2→WEBサーバのEC2をサブネット分けて構築するとか、静的ホスティングならCroudFront+S3でいいよねとか。
後はサービスの組み合わせではないですが、特にDB系のサービスの可用性の担保の仕方が大体わかります。
そのため、「とりあえずこういうことがしたくて、それなりに安全に作っときたい」というときに、アーキテクチャを決められるようになると思います。
書いていて思いましたが、これがまさにソリューションアーキテクトですね。
- 今使っているサービスの知らない機能を知ることができる
とりあえず動かしているだけのサービスだと、意外と知らない機能があったりします。
今のシステムを改めて確認して、改善できそうです。
(例)
・S3のライフサイクル管理
期間を設定しておくと、その期間経過したら削除orS3 Glacierにアーカイブしてくれる。
・DynamoDBのTTL
上と似ているが、有効期限決めておくと経過後に登録しているデータを削除してくれる。
DynamoDBは全件を検索するのがキーをうまく設定しておかないと難しいから、件数増えすぎると大変。
・EC2 Image Builder
EC2のテンプレートみたいなものを作れる。かつ、そこに最初からインストールしておくもののバージョンアップも自動で設定+テストできる。
勉強方法
SAAに関しては勉強方法のブログがめちゃくちゃありますが、一応私も載せておきます。
大体2か月くらいの勉強でした。平日たまに、休日そこそこ。大体50時間くらいかけたかな?
前提
約2年間、AWS上でデータ分析系の業務してます。
ただ、いわゆる普通のシステム構築はしてません。
以下、触ってる/触ってないサービスです。
触ってる:S3、Glue、StepFunctions、SQS、Lambda、SageMaker、DynamoDB、CloudFormation
触ってない:EC2、ELB、Route53、VPC、CloudFront、RDS、Aurora
前半1か月の過ごし方
とりあえず、この資格で出てくるサービスを広く浅く理解しよう!と思い、勉強しました。
具体的に使ったのは、以下の2つです。どちらもかなり良かった。
①書籍:AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版
広く浅く、SAAで出てくるサービスを紹介してくれています。
さらっと目を通すのを何周かするのがおすすめ。
確かにこの本に載っていない機能についての問題が出ることもありますが、そこまで多くない印象でした。
②Udemy講座:【2022年版】これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
この講座は、控えめに言ってGODです。
ボリュームすごい(全部で40時間以上)、1つ1つが分かりやすい、ハンズオンついてる、模擬試験3つついてる
この内容で、2000円くらい。(udemyのセールの時に買うともっと安い!)
これは全人類見るべきだと思います。
といっても、さすがにこれ全部やるのは大変なので、以下だけやりました。
これらは、この試験でもよく出てくるところなので、ハンズオンもしっかりやることをお勧めします。
ハンズオンでやってやった操作内容がテストに出ることはあまりないですが、知識の定着が早まった気がします。
・全体像【Selction1~3】
・IAM【Selction4】
・VPC【Selction5】
・EC2【Selction6】
・信頼性の設計(ELB/Auto Scaling/RDS)【Selction9】
後半1か月の過ごし方
大体全体的に知識がついたので、過去問を解く&分からなかったところを調べるを繰り返しました。
具体的には、前半で紹介した②のUdemyの最後についてきた模試と、この講座。
③【2022年版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)
この模擬試験を3回分受けました。(6回受けたかったけど、時間がなく断念…)
本番よりも難しいと書いてありましたが、確かにそう感じました。この模試だと60%くらいしか取れませんでしたが、本番は80%取れたので。
ただ、この模試の難しさは、どちらかというと「試験では聞いてこないような機能についても聞かれる」難しさな感じがします。
本番は、模試よりも問題文が長く、直接すぐ答えられるような問題が少ないです(取り出しに5時間時間かかってよい時は?→S3 Glacier標準 など)。
なので、この模試もそうですが、問題文と答えを暗記するというよりは、「こういう条件だから、このサービスのこの機能を使ってるのか」と理解するのが大事だと思います。
www.udemy.com
模試の振り返り方法
勉強している最後の方に、なかなか良い方法を見つけたので記載します。
模試で間違えたところや知らなかった内容を、このようにスプレッドシートでメモしていきました。
こうすると、後日さーっと上から眺めることで知識を確認できます。
あと、C列の種類をソートするとサービスごとにまとめられるので、さらに知識定着が進むと思います。
(もっと早くからやりたかった…)
書籍「実践的データ基盤への処方箋」を読んだ
今年初めての5連続仕事を乗り切った皆様、お疲れさまでした。いかがお過ごしでしょうか。
今日は、私の業務にも関係している、データ基盤に関しての本を読んだので自分的なまとめを書いていこうと思います。
どんな本?
一言でいうと、「データ基盤作りました!だけじゃダメなんよ」という本。
冒頭で、著者はこのように言っている。
- 真のデータ活用とは、一時的ではなく、継続的に企業の成長を支えることである。
- しかし、企業においてこれができているかというと、そうではない。
- データ基盤の作り方のノウハウは世間的にも認知されてきているのに、なぜか?
- 「データ基盤の活用のさせ方」が広まっていないからである。
確かに、データ基盤の作り方という意味では、巷にはパブリッククラウドを使ったハンズオンや、pythonの書籍などがあふれかえっている。
それにも関わらず、データ分析基盤作りがうまくいかない!という声は、よく聞くように思える。
思うと、こういうギャップは日常生活でもよく起きているように思う。
- 実家の親がスマホに変えたいということで手続して変えてあげたが、使いにくそうにしている。
- 仕事でチームのタスク管理のためにチケット管理ツールを導入したが、だれも使ってない。
- 同居人が「初めて資料作成の仕事を任された」というので、実際に自分が参考にした書籍やサイトを送ったが、何も見ない。
このように、使う側と提供する側が違うと、このようなことが起こりうるのだろう。
今回は、その「データ分析基盤版」というわけだ。(キバンバンって語呂悪いな…)
この本では、実際のビジネスの現場で起きた課題、解決したノウハウをデータ/システム/ヒトの観点で紹介している。
今回は、その中でも私が重要だと思った「データ」の観点の中から、特に大事なべし/べからずをピックアップして紹介する。
ユースケースからつくるべし(not データ基盤)【1-9】
why?
ユースケースがビジネス価値を生むものだから。基盤だけ整えても、「結局何がしたかったんだっけ?」となりがち。
how?
- 自社の目標、現状、課題、施策を洗い出す。
- 施策の優先順位を決める。
- その施策の中で、「どの顧客or社員の」「どの作業or判断を」「どのように置き換えるか」を検討する。
(例)
デジタル広告配信による登録促進、という施策の場合。
・経営企画部門が売り上げを集計している→手間削減のためにダッシュボードを作る
・顧客自らページをクリックして商品を探している→手間削減のために検索機能を作る
このあたりのユースケースへの落とし込みは、この本だけだと詳細には分からなかった。
著者からも、「業務改善やUXデザインの手法が役に立つからほかの書籍を参考にしてみてね」ということだった。
この部分に関しては、このブログ記事がよく言語化されている。
ただ、やはり実際の経験が積みたいところ。仕事であればいいが、なにか過去事例などないものか…。
【保存版】初心者でも分かるデータ分析の本質とスキルアップの道のり|naki|note
サービスレベルを設定/計測して継続的に改善するべし【1-11】
why?
ユーザが期待しているサービスレベルをクリアしないと使われなくなっていくから。
how?
ユースケースごとにサービスレベルを設定し、そのサービスレベルが守れているかを定期的にモニタリングする。
(例)
毎営業日の午前9時までに欠損なく前日の売り上げレポートが作成されていること
この「サービスレベル」は、なかなか難しい。なぜなら、ユーザにざっくり「守るべきサービスレベルって何にすればいいですか?」と聞いても答えが返ってこないだろうからだ。
(もちろん、例のようにはっきりしているものもあるだろうが、ユーザの暗黙的な期待もあるはず。)
SIer思考だと、サービスレベルの種類を網羅したどでかいexcelがどこかにあって、その1行ごとにレベルを定義してユーザと合意したくなる。
以下の非機能グレードのように。
システム構築の上流工程強化(非機能要求グレード):IPA 独立行政法人 情報処理推進機構
ただ、データ分析基盤では、とりあえずエイヤで分かりやすいレベルだけ決めて、定期的に振り返っていき、途中で何か問題が起きたらサービスレベルに追加していくのがいいのだろう。
例えば、nullが入らないはずのidカラムにnullが入ってしまっている、という障害が起きたら、csvファイルのnullチェックを実装してモニタリングする、など。
著者の1人であるゆずたそさんのブログで、この部分はより詳細に述べられていた。
サービスレベル:設計と運用のプラクティス - 下町柚子黄昏記 by @yuzutas0
また、オライリーのこの書籍も参考になりそうだ。
利害対立が生じる、データの生成者と活用者をうまくつなげるべし【1-3, 1-10】
why?
- データが高品質で利用できる形で生成されないと、データ活用者がデータをうまく使えないから。
- データソースに一番詳しいデータ生成者がメタデータの更新作業をしてもらわないと、データ活用者のデータ調査コストが膨れ上がるため。
おわりに
以上、重要そうなところだけをピックアップし、参考になりそうなものがあれば載せてみた。
この中でも特に重要なのは、1つ目のユースケースに関わるところだろう。
ユースケースがうまく決まれば、あとはそれをどう検証/実現していくかという話になるので、動きが速い。
また、ユースケースはビジネス価値に直結するので周りも説得させやすい。
インフラエンジニアでも、データスチュワードでも、「どのようにビジネス価値につながっているのか」は、常に意識しておくべきだろう。
案件が来るたびに、それを確認するような仕組みを作っておくとよいかもしれない。
仕組みは文化を創り出す。ビジネス価値を意識できるチームは、強いチームになれるはずだ。
アードベッグ5年と10年飲み比べ
変わらず寒い日が続く昨今、皆様お元気でしょうか。
そんな寒い日は、やはりお酒を飲んで暖かくなりたくなりますね。
それも、暖炉の前で、ウイスキーのストレートをぐびっとやりたくなるものです。
ということで、今日は私の大好きなウイスキー、アードベッグ10年と5年の飲み比べ記事です。
そもそもアードベッグとは何か。
・ピート臭(焦げ臭い、薬品臭い)がすごいことで有名。
・今回のむTENがスタンダード品。
・これを好きな人々はアードベギャンと呼ばれる
という知る人ぞ知る名ウイスキーです。
年に1度、アードベッグデイというイベントが行われ、そこで毎年新作が飲めます。(その新作をボトルで買うのはかなり大変。このイベントで飲むことはできる)
さて、上記の通りTENはスタンダード品ですが、2020年に発売したのがこのアードベッグ5年 WEE BEASTIEです。
あまりそこら辺でも売っていないというのをネットで見ましたが、近くのカクヤスで売っていたので購入。
そして、年末になくなっていたアードベッグTENを購入したので、この記事を書くことにしました。
ご尊顔。
まず、ボトルがかっこいいですよね。ミドリのボトルに黒メインの色遣いが厨二心をくすぐります。
5年の方の赤もワンポイントでかっこいい。最高。
テイスティング
色
5年の方がちょっと濃いめ。10年は薄い。
5年の方は、少し赤見がかかってる?
香り
5年は、炭+オイリーな感じ。なんか重い、のっぺりした感じ。このオイリーさ、私はちょっと苦手。
10年は、潮っけ。からのちょい甘さ、柑橘。嗅ぐと海が頭に広がる。
ストレート
5年は、香りの方にあったオイリーさが来る。フィニッシュにかけては炭っぽさ、苦み。香りがそのまま味に反映されている。
10年は、やはり潮っぽさ。口いっぱいに広がる。後味は爽やか系。しょっぱさの中に炭な感じ。
ちょい加水
5年は、ストレートとかにあったオイリーさが薄まってちょっと飲みやすく感じた。
このオイリーさ、なんだろうと思ったけど、この前かったロイヤルロッホナガー12年にちょっと似ている。
シェリー樽の味なのかな?(この5年はオロロソシェリー樽を使っているらしい)
10年は、ちょい加水すると後味に合った炭ぽさが強くなってきた。
トゥワイスアップ
5年は、ちょっとしょっぱい感じになってきた。後味のところは薄まって、ほぼない。
10年は、柑橘感がかなり出てくる。炭っぽさはほぼなくなる。
しかし、トゥワイスにしても両者しっかりウイスキーの味がする。さすが。
ロック
5年は、ロックにするとごくごく飲める。上にあったオイリーさはあるけど、奥の方に炭がいる。
10年は、しょっぱさ、そして青りんご感。炭感はあんまりない。
ハイボール
5年は、やはり一貫してオイリー感。ただ、それがシュワっとなった感じ。うまいけど、なんかちょっと重い。
10年は、柑橘感がメインでサブに炭っぽい燻製感。爽快感すごい。ってかマジでうまい。