「Goならわかるシステムプログラミング」第2章メモ
隣の席のパイセンに借りたこれが積読になってたので読んでいってる
- 作者: 渋川よしき
- 出版社/メーカー: Lambda Note
- 発売日: 2017/10/19
- メディア: テキスト
- この商品を含むブログを見る
ダラダラ読んでも分からないので、だいたい3行ずつくらいでまとめた
最後に問題がついているのでそれもやってみる(まだ途中)
とりあえずまとめ
2.1 io.WriterはOSが持つファイルのシステムコールの相似形
- OSのシステムコールはファイルディスクリプタに対して呼んでいる
- POSIX系OSでは可能な限り様々なものが「ファイル」として抽象化されている
- io.WriterはGo言語のインターフェイスをいう仕組みとして実装されている
2.2 Go言語のインターフェイスt
- Go言語のインターフェイスはJavaと同じく、持つべきメソッドを表現するための言語機能
- インターフェイスを満たす構造体を定義する時に「implements」などのキーワードは必要ない
- 副作用のあるメソッドではレシーバの型をポインタ型
h *Hoge
にする
2.3 io.Writerは「インターフェイス」
- syscall.Write()は「osパッケージのFile型に定義されているWrite()というメソッド」
- 「バイト列bを書き込み、書き込んだバイト数nとエラーerrorを返す」という振る舞いは様々なものに適応できる
- io.WriterはWrite()メソッドが宣言されているインターフェイス
2.4 io.Writerを使う構造体の例
- io.Writerインターフェイスを満たす構造体は、ファイルや画面出力、Bufferなど様々なところで実装されている
- 特にnet.Dial()関数を使ってインターネットにアクセスできるのがGoらしさ
- io.Writerを受け取り、データを加工して別のio.Writerに書き出す構造体もある(デコレータ)
2.5 インターフェイスの実装状況/利用状況を調べる
- Goでは構造体がインターフェイスを満たすメソッドを持っているかどうかは、コードを単純に検索するだけでは分からない
- godocというコマンドを使えばgolang.orgのパッケージのドキュメントをローカルで見ることができる
- インターフェイスを満たしている構造体などを一覧で見ることができる
2.6 低レベルの機能を組み合わせて入出力APIを作る
メモの良い感じな運用方法を考えている
背景
- 近年、メモはノートではなく、PCやスマホのメモ機能を使うことが多い。
- マークダウン出かけるものや、カテゴライズなど、様々な機能が利用できるようになっている。
- しかし、そんな便利なメモを運用していく中で、いくつか問題点が出てきた。
- そこで、今後どうやって運用するかを考えてみた。
何が問題点だったか
- カテゴリが多すぎてよく分からない
- vue, frontend, infra, workstyle, LTネタ, アプリネタ, etc.
- カテゴリごとの記事が少なくてカテゴリ分類が意味をなしていない
- 1つしかメモが入ってないカテゴリとかあった
- blockchain, payment, etc.
- かといって1つの記事にたくさん書くと後で読みにくい
- スクロールしんどい
- たくさん書いてるけど、なんか内容が微妙
- 少なくとも人に見せれるものではなかった
どうやって解決するか
最初からカテゴリ分けしない
- 設計でもそんな考え方あったよね
- まずは大きなジャンルでいいので1つのメモに書いていく
ある程度分量が出てきたらアウトプットを行う
- ブログでもnoteでもMidiumでもOK
- アウトプットを意識して書くようになるため、質も上がる(はず)
アウトプットした分を参考資料としてメモに載せておく
- アウトプットすればするほど、メモ自体の分量が減る
- メモ上で見やすいように、記事のタイトルを分かりやすくしておく
目指す状態
- 自分の記事で構成されるアウトプットのリンク集
- 修正がある場合は、アウトプットした方を修正する
- 修正日時を追記しておく
もしカテゴリを分けるときは
単純に分量が多いものを切り分ける
- 無理して排反関係を作らない
- 大体のものは複数のジャンルを持ち合わせているため、すぐにこれどっち?ってなる
最後に
良い感じにカテゴリ分類してたら、どんな感じか教えてください(><)
3分でわかった気になる、Kubernetes とは?
マイクロサービスやDockerの話になるといつも出てくるのが、Kubernetes(クーベネティス)。
奥深そうな技術ではあるが、Kubernetesとは?を浅く簡単にまとめてみた。
概要
- Dockerコンテナをクラスタ化した際の運用ツールの1つ
- Googleが中心になって開発してる(Go + シェルスクリプト)
- 自動デプロイ、スケーリング、アプリ・コンテナの運用自動化ができる
- マイクロサービスと相性が良い
- 管理上の基本単位はPodという
- Volume:記憶領域を共有するコンテナの集まり
- Container
- IP ADress
- 試すなら、GKE(Google Container Engine)を使うのが良さそう
↓こんな画面らしい
↓8分くらいの動画。わかりやすいらしい(見てない)
なぜ必要とされたのか?
- Dockerは、ホスト内のコンテナ同士はやりとりできるが、外側とのやりとりにNATが必要
- したがって、ホスト間の連携が煩雑になるため、容易にスケールアウトできない
- そこで出てきたのがKubernetes
Kubernetesでできること
- 複数台のホストから構成される実行環境を、1台の実行環境のように扱うことができる
- 運用中のコンテナに不具合があってサービスがダウンした時に、状態変化を察知し、いい感じにしてくれる
- 問題の発見に遅れる可能性があるかも
- Docker/Kubernetes環境でマイクロサービス化を推進すると、様々な部品を独立してデプロイ出来るようになる
つまり
- アプリを迅速に予定通りにデプロイする
- 稼働中にアプリをスケールする(規模を大きくする)
構成要素
次はハンズオンをやりながら理解を深める予定
参考サイト
3分で分かった気になる、Elasticsearchとは?
ログ解析等でよくElasticsearch+kibanaが使われているが、改めてElasticsearchとは?を簡単にまとめた。
概要
- Elastic社が開発している、スケーラビリティに優れた全文検索エンジン
- リアルタイムデータ分析、ログ解析、全文検索など様々な分析が可能になる
- ログ集約のLogstashやfluentd、可視化ツールのkibanaと一緒に使われることが多い
- 複数のデータベースを横断して検索することが、ごく当たり前の用途として提供されている
RDBの違い
RDB:
- データを安全に保管し、汎用的に利用するための機能が豊富
- データベースをドロップすることはなかなかない
- マスターとなるデータを半永久的に保管する
Elasticsearch:
- 検索のパフォーマンスとスケーラビリティが強い
- 時間間隔でインデックスを区切ったりすることがよくある
- 不要になったインデックスは捨てる
- 分析や検索用のデータを保管する
それぞれ呼び方の違い
RDB | Elasticsearch |
---|---|
データベース | インデックス |
テーブル | マッピングタイプ |
カラム(列) | フィールド |
レコード(行) | ドキュメント |
使い方の基礎
第4回 Elasticsearch 入門 検索の基本中の基本
- サーチAPIを利用して様々な検索を行う
- 検索やデータの投入、削除はJSON形式で指定することができる
- 本番環境の検索はエイリアス名を使う
- ページング
- sizeとfromを使う
- size:1度の検索結果を取得する数をしている。デフォルトは10
- from:スキップする結果数を指定:デフォルトは0
検索のパワーをフル活用するなら
以下の知識が必要っぽい
参考記事
PWA(Progress Web App)についてなんとなく知る
Progressive Web Appとは
機能でいうと、以下が利用可能に - アイコン追加 - スプラッシュスクリーン - オフラインキャッシュ - プッシュ通知
オフラインキャッシュやプッシュ通知は【Service Worker】の機能が利用されている。 Service Workerとは、ブラウザの裏側で指定通りに働く「ワーカー」である。
- 他にもAMPとの併用可)
AMPとは、モバイルのWebページを高速化するもの 詳しくはまた調べる必要がある。
PWAのメリット
- App Store等のアプリストアから出す必要がない
- リリース/アップデート時の審査が不要になる。
- OSごとの個別対応が不要
- HTML, Javascriptで実装可能
PWAの注意点
簡単なまとめ
ネイティブアプリをわざわざPWAに置き換える必要はないが、 これから新しくアプリを作る予定であれば、PWAも視野に入れてみては。
【サーバ/インフラを支える技術】を読んで、めちゃくちゃ簡単にまとめていく
最近はシステム構成図を見ることが多くなってきた。 見てもよくわからないことが多いので、何か勉強しようと思い、 【サーバ/インフラを支える技術】を読んだ。 せっかくなので、目次に毛を生やした程度にまとめてみた。
【第1章】サーバ/インフラ構築入門
- システムは、障害がいつ起こってもいいように設計しなければならない
- そのためには、ルータ、ロードバランサ、サーバ、全てを冗長化する必要がある
- 冗長化した際に大切なことは、
- 障害の検出(ヘルスチェック)
- スムーズな切り替え(IPアドレスの引き継ぎ)
- スケジューリングアルゴリズム、VRRP、色んな仕組みが使われている
【第2章】ワンランク上のサーバ/インフラの構築
- キャッシュサーバをリバースプロキシとして使うと、APサーバへの負荷分散ができる
- MySQLも冗長化(レプリケーション)し、かつスレーブを有効活用する
- HTTPをストレージプロトコルとして利用することで、サイトが全停止する危険を回避
- 単一故障点を防ぐために冗長化が必要
- 複数台のサーバにファイルを同期さると不具合が起きやすい
- これら2つの課題は第3章で
【第3章】止まらないインフラを目指すさらなる工夫
- DNSサーバの障害はなかなか起きないが、起こった時には原因特定がかなり難しく影響範囲が広い
- ロードバランサにVIPを持たせ、Active/Active構成で冗長化する。(IPVS, keepalive)
- ストレージサーバの同期は困難 -> DRBDを用いて解決
- DRBD:ファイル単位ではなく、ブロックデバイス単位でリアルタイムにレプリケートする
- keepalivdをdaemontoolsで制御する
- 誰かが間違えてファイルを消すと即座にバックアップに反映してしまうのが弱点
- Bondingドライバを用いて、L1,/L2も冗長化する(リンク、スイッチ)
- 冗長化しすぎるとループができてしまう(ブロードキャストストーム)
- RSTPで解決(自動的に冗長な接続を遮断する)
- VLANを用いてネットワークを柔軟に
- ポートVLAN:スイッチのポートごとにVLAN識別子を割り当てる
- タグVLAN:EthernetフレームにVLAN識別情報を挿入する。論理構成が複雑になりがち。
- サーバファームでの利用は、タグVLANを使用することで、物理的な無駄を無くせる
- ポートVLANを基本とし、必要なところにタグVLANの設定を行うのが理想
- VLAN構成が複雑になっても、物理構成はシンプルさを求める
【第4章】性能向上、チューニング
- これまでの冗長化に合わせて、単一のホストの性能を引き出すことによって初めて負荷分散の意味がある
- Webサーバ(Apache)にもチューニングはできるが、ほとんどの原因は別の場所に存在する
- 強いてあげるなら、並列処理の際のMPMに何を選択するかが重要になる
- サーバが搭載する物理メモリと1プロセスの平均メモリ消費量によってMaxClientsを決める
- perfork:マルチプロセス。普段使いならこちらで良い。
- worker:マルチスレッド。軽量で高速であるが、設定が複雑。
- MySQLのチューニングはテーブル設計やSQLの最適化が効果的
- サーバサイドで出来ることは、メモリ関係のパラメータチューニング
- バッファ:innodb_buffer_pool_sizeとかとか
【第5章】省力運用
- 省力運用のために様々なツールが用いられる
- Nagios:サービスの稼働監視
- 死活状態
- 負荷状態
- 稼働率の計測
- Ganglis:サーバリソースのモニタリング
- Puppet:サーバ管理の効率化
- 新規サーバの投入
- 既存サーバの設定変更
- 台数が多いところ、手動では設定漏れが発生しがちなところが優先
- deamontools:デーモンの稼働管理
- プロセスが落ちた時に自動で起動しなおしてくれる
- 手軽にデーモンを作れる
- PXE、initramfs:ネットワークブートの活用
- ネットワーク上のサーバから読み出すため、二次記憶装置が必要ない
- ロードバランサやDB,ファイルサーバに活用されることが多い
- リモートメンテナンス
- SSHでリモートログインすると楽だけど、OSが起動していないと使えない
- シリアルコンソール、IPMI等を用いて対処する
- Webサーバのログの扱い
- ログを扱いやすくするためには、1つの場所に集約、収集する必要がある
- アクセスの集計やトラブルの解析に利用される
SEOについて少しだけ調べた
SEOについてわかっていること - 検索で上位に出てくるように - metaタグ?かなんかに仕込むとか - インデックスがどうのこうの
概要
検索エンジンの仕組み
必須の仕組みとして、
- クローラー
- Web上のあらゆる情報を収集するプログラム
- インデックス
- 抽出可能な形に整理された検索データベース
クローラーによって収集されたWebページの情報がインデックスと呼ばれる検索データベースに登録され、検索された言葉に対応する検索結果を瞬時に返す
また、検索キーワードに応じて得点付するための仕組みを"検索アルゴリズム"という。
このブログの検索エンジン最適化してみる
はてなブログでは、設定で3つの項目を設定することでSEO対策を行うことができる
- ブログの概要(meta description)
- ブログのキーワード(meta keywords)
- headに要素を追加
SEOの基本として、<head>
内タグを最適化する必要がある
<title>タグ
:検索エンジンがページの内容を理解するのに重要視するポイント- 文字数は70バイト(全角35文字)以下
<meta name="description>"
:説明文として出てくるため、クリック率に影響が出る- 文字数は160~220バイト(全角80~110文字)以内
<meta name="keywords">
:SEOには関係ないらしい。しかし、動的検索広告を利用する場合には必要- 2つ〜5つ以内
最適化されたかチェックする方法
Google Search Consoleを使用する この辺りはまた別の機会にまとめます。