Carpe Diem

備忘録

structのメモリ割り当て

概要

Goにおけるstructのメモリ構造を知ることでフィールド順序に対する意識が変わったり、なぜunsafe.Sizeof(string)16bytesunsafe.Sizeof(slice)24bytesになるかが理解できます。

環境

各型のメモリ割り当て

unsafe.Sizeof()を使うとその変数がどれくらいメモリを割り振るかが分かります。
※変数の分確保するメモリであり、参照先のメモリは含みません

unsafe.Sizeof()
bool 1
int32 4
int 8
float64 8
string 16
[]T 24

The Go Playground

structのフィールドにそれぞれの型を付けると、その分メモリが割り振られます

続きを読む

GoでShutdown Hook

背景

以前Graceful shutdown機能の使い方を紹介しました。

christina04.hatenablog.com

これによって処理途中のリクエストが残っていても、きちんと完了するまで待ってからプロセスを終了してくれます。

しかしPubSubのPublish()のような非同期処理であればリクエストが完了しても内部でキューが残っており、単純にそのまま終了するとメッセージがロストしてしまいます。なのでプロセス終了までにStop()を呼び出す必要があります。
またミドルウェアとのコネクションクローズといった後処理も、SDKにメソッドが用意されているのであればプロセス終了までに呼び出すべきです。

このようなプロセスが終了するまでのやっておきたい後処理を、あらかじめ登録しておき最後にまとめて呼び出す仕組みをShutdown Hookと呼びます。

JavaではRuntimeに用意されていますが、goでは用意されていないので自前で実装する必要があります。

続きを読む

継続的プロファイリング

背景

過去にいくつかpprofの使い方を紹介しましたが、実際に運用する上では以下の課題があります。

  • 何かしら問題が発生して初めてプロファイリング開始するという後手になりがち
  • 問題の再現が難しく、再び発生するまで様子見という流れになりがち
  • プロファイリングしたことがないメンバーにとってオペレーションコストが高い
  • バージョン比較ができない

これらの課題を解決するために、継続的プロファイリング(Continuous Profiling)を導入します。

続きを読む

GCPのCloud PubSubで考慮すること

概要

GCPのCloud PubSubはメッセージング基盤として非常に有用です。
ただし利用する上で考慮すべきことも多々あるのでまとめておきます。

パラメータに関しては主にgolangのクライアントライブラリをベースに説明します。

環境

  • go 1.15.2
  • google-cloud-go v0.72.0

SLO/SLA

Cloud PubSubのSLOは99.95%です。
自身が提供するサービスのSLOを満たすかはこれを元に利用しましょう。

それを満たせなかったときのSLAとしては以下のように決められています。

各月の稼働率 対象サービスが SLO を満たさなかった場合、お客様の翌月以降の請求書に対して返金される月次請求額の割合
99%~99.95% 未満 10%
95%~99% 未満 25%
95% 未満 50%

ref: Pub/Sub Service Level Agreement (SLA)  |  Cloud Pub/Sub Documentation

続きを読む

データ暗号化で考慮すること(鍵編)

概要

前回の続きです。

christina04.hatenablog.com

今回は暗号化における鍵(共通鍵)について説明します。

前提知識

鍵とは

鍵とはとても大きな数です。
鍵のビット長が大きい=鍵空間が大きいことを意味します。つまり可能な鍵の総数が大きいため総当り攻撃が困難になります。

AESでは128bits, 192bits, 256bitsのビット長の鍵を選択できますが、長いほど鍵空間が大きくて良いということになります。

続きを読む

データ暗号化で考慮すること(暗号アルゴリズム編)

概要

ユーザのメールアドレスといった機密情報を暗号化・復号したいユースケースがあるとします。
メール送信などに利用するためパスワードのようにハッシュ化するのでなく、復号して利用したいケースです。

機密情報の管理全般については以前↓で話しましたが、今回はデータの暗号化に焦点を当ててみます。

機密情報の管理で大切なこと - Carpe Diem

前提知識

適切な暗号方法を理解していないとZoomで問題になったように脆弱性のあるアルゴリズムを使用してしまいます。

Zoom documentation claims that the app uses “AES-256” encryption for meetings where possible. However, we find that in each Zoom meeting, a single AES-128 key is used in ECB mode by all participants to encrypt and decrypt audio and video. The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption.

ref: Move Fast and Roll Your Own Crypto: A Quick Look at the Confidentiality of Zoom Meetings - The Citizen Lab

なので暗号における前提知識を説明した後に具体的な実装を紹介します。

続きを読む

パスワードを保存するときに考慮すること

概要

パスワードを保存する際は平文で保存せずハッシュ化するのは当然です。しかし単にハッシュ化するだけでなく

  • 暗号学的に優れたハッシュ関数を使う
  • saltを付ける
  • 計算コストのかかるアルゴリズムを採用する
  • ストレッチングで計算コストを上げる

といった点を考慮することで、万が一ハッシュ化されたデータが漏洩してもそこから平文が算出されないようにすべきです。

続きを読む