はてなブックマーク

わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

はじめに GitHub Actionsは、GitHub上のコードに対して、PushやPullRequestをフックして、処理を実行できる処理基盤です。 このGitHub Actionsを使って自動テストや自動デプロイをするのですが、GitHub ActionsのワーカーのグローバルIPアドレスは毎回変わるため、Src IP制限のかかったサービスを使おうとするとうまくいきません。 そこで、この記事では、GitHub ActionsからSrc IP制限のかかったサービスを使う方法を、AWSのRDSを例に上げて説明します。 概要 処理の概要は以下のとおりです GitHub ActionsのワーカーのグローバルIPを、haythem/public-ip@v1.2 を使って取得する RDSのSecurity Groupに対して、取得したグローバルIPからの通信を一時的に許可する サービスにつないでや

import os import subprocess def exec_os_system(cmd: str): ''' コマンドを同期実行し、 標準出力と標準エラー出力は、実行したプロンプトに随時表示する 戻り値はコマンドのリターンコード ''' # os.systemはwaitで子プロセスの終了を待つため、リターンコードの上位8bitにリターンコードが格納される # それを取るため8bit右にシフトする # see http://d.hatena.ne.jp/perlcodesample/20090415/1240762619 rt = os.system(cmd) >> 8 return rt def exec_subprocess(cmd: str, raise_error=True): ''' コマンドを同期実行し、 標準出力と標準エラー出力は最後にまとめて返却する raise

$GOPATH以外の場所でimportをするとハマることが多い。 それは以下のパターンが有るからだ。 GOPATHモードとモジュールモードの違い GitHub上にあるような外部パッケージと、ディレクトリの中に有る内部パッケージの違い これらそれぞれについて、importがどう違うか整理する。 (GOのバージョンは1.14を想定している) ざっくりまとめ 結論の概要を書くと以下のような感じ 外部ライブラリ GOPATHモード→探す先は$GOPATH/src モジュールモード→探す先は$GOPATH/pkg/mod 内部ライブラリ GOPATHモード→探す先は相対パス モジュールモード→探す先はgo.modにかかれたmodule名+go.modがあるディレクトリからの相対パス はじめに 環境 OS: MacOS GO言語: go version go1.14.3 darwin/amd64 GO

やりたいこと 個人用途で、Pythonのクライアントライブラリ(google-cloud-bigquery)からBigQueryのAPIを叩きたいみたいなケースを考えてください。 インターネット上のブログの多くでは、サービスアカウントを発行して、jsonの鍵を取得し、GOOGLE_APPLICATION_CREDENTIALSの環境変数に指定する方法が紹介されています。 ですが、個人ごとにサービスアカウントを発行するのは面倒です。 こうすればできる 個人の権限（＝ユーザアカウント）を用いて、プログラミング言語のクライアントライブラリからGCPを利用する場合は gcloud auth application-default login コマンドを利用します やり方は簡単で、ターミナルなどで以下のコマンドを実行します そうするとWebブラウザに飛ばされ、そこで個人の権限でGCPの認証をすれば、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MongoDB World 2016にて、MongoDBサービスの「MongoDB Atlas」（モンゴデービーアトラス）が発表された。これは自前でMongoDBを立てる場合とは違って、コンソールからクリックしていくだけでMongoDBのクラスタがAWS上に立ち上がり、利用した分だけ課金されるサービスだ。 ポイント 要はMongoDB Atlasは MongoDB社公式のマネージドサービス アカウント作ってWebで操作すると、AWS上にMongoDBのクラスタが立つ アプリからはインターネット経由でアクセス。プロトコルはMongoDBプ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

AWS SDKでSignatureDoesNotMatchがでたり、AWS CLIでRequestTimeTooSkewedがでた。原因はOS時刻遅れaws-cliaws-sdk <?xml version="1.0"?><ErrorResponse xmlns="http://queue.amazonaws.com/doc/2012-11-05\ /"><Error><Type>Sender</Type><Code>SignatureDoesNotMatch</Code><Message>Signature ex\ pired: 20160521T123018Z is now earlier than 20160521T130541Z (20160521T132041Z - 15 \ min.)</Message><Detail/></Error><RequestId>2cfb54a3-

7年前に書いたRuby 1.8 + Rails 1.2.6 + MySQL 5.0のアプリがあり、ほとんど使ってないけど、たま～に使うので、扱いに困っていました。 そこで、今動いているミドルウェアのバージョンをそのままにDockerでコンテナ化して、どんな環境にも移動できるようにしました。これでどこでも昔のバージョンのまま動き続けることができる、いわるゆ塩漬けです！ それを紹介します。 Dockerの実行環境 CentOS Linux release 7.1.1503 Docker version 1.10.3, build 3999ccb-unsupported 塩漬け対象アプリの構成 ミドル Ruby1.8.7 Ruby on Rails 1.2.6 MySQL 5.0.77 アプリ bitbucketにあるレポジトリを/usr/local/myappにcloneして動作させる データ

仕事上Pythonでスクリプトをよく書くので、雛形コードを備忘録も兼ねて載せておきます。 python3系の雛形 python 3.3以降を対象としています。 概要 この雛形では以下のことをしています。 コマンドライン引数のパース(clickの利用) 設定クラスの読み込み ログ出力(loggingの利用) ライブラリ読み込み ライブラリの単体テスト ファイルの配置 app_home/ ├ bin/ │ └ my_batch.py #←実行するスクリプト ├ conf/ │ └ my_batch_conf.py #←設定クラス ├ lib/ │ └ my_lib.py #←ライブラリ ├ tests/ │ └ test_my_lib.py #←単体テストコード ├ log/ #←ログ出力先 └ Pipfile #←使うライブラリを列挙 import logging import os imp

(2016/1/11追記) このブログはMongoDB 3.2がリリースされる前に公表された情報であり、3.2の正式なリリース情報ではありません。MongoDB3.2の正式なリリース情報はMongoDB3.2リリースノートの説明を見てください。 はじめに MongoDB 3.2のアナウンスが出ましたので、ざっくり説明します。 基本的にはアナウンスを元に、足りない部分はリリースノート(RC版)で補足しています。 アナウンスの要約 ドキュメントバリデーション ドキュメントの中身にバリデーション(キー名や値のチェック)がかけられます。 例えば、{ age : { $gte : 0, $lte : 150 } }とすると、ageが0～15の間の数値であるかチェックできるといった感じです。 部分的インデックス ドキュメントの中のある値によって、インデックスに含めるかどうかを分けれるようになります。

Dockerのセミナを受けたので、とりあえずDockerの勉強のためにMongoDBをDockerでインストールしてみた。 環境 * CentOS 7.0.1406 (Core) * docker-1.3.2-4.el7.centos.x86_64 Dockerのインストール yumでインストールして、その後systemctlコマンドで起動する。

MongoDB 3.0から従来のmmapベースのストレージエンジンから、Wired Tigerというストレージエンジンが使えるようになった。 主な変更点は以下のとおり。 mmapベース MongoDB ver 3にはMongoDB ver 2にあったmmapベースに改良を加えたものが乗っている MongoDBはOSのmmap()システムコールを読んで、OSにデータファイルをメモリに載せてもらう。 MongoDBはメモリを管理しない。OS任せ。 メモリ使用量を制限できない。OSから与えられるだけ使う。 メモリがいっぱいになるとOSが適宜スワップさせる データ圧縮できない コレクションレベルロック（ver 2のころはデータベースレベルロック） インデックスとデータは分離できない（同一ファイル内に混在） Wired Tiger MongoDB ver 3からの新規 Wired Tigerというス

[mongodb-org-3.0] name=MongoDB Repository baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/ gpgcheck=0 enabled=1

CentOS 7をインストールして謎だったことの一つとして、ネットワーク名が今までの「eth0」みたいなやつから、「enp1s0」みたいな謎の文字列に変わった事がある。 気になったので調べてみた。 ネットワーク名は新しい命名規則に沿って自動的に作られる 調べていると、以下のブログに丁寧に説明が書いてあった。 Predictable Network Interface Names ざっくり訳すと以下の通り v197のsystemd/udevでは自動的に安定的なネットワークインターフェース名を割り当てる。 ローカルエリアネットワークに限らず、WLANやWWANに対しても割り当てる。 伝統的な ("eth0", "eth1", "wlan0", ...)といった命名規則はもうしない。 新しい命名規則では以下の嬉しい事がある。 OSが再起動してもインターフェース名が変わらない ハードウェアを追加し

ひどく個人的なノウハウですが、私がCentOS 7 を入れたら最初にやることです。 DVDのisoからブート。最小構成で入れて、NICの設定はインストラーでGUIで設定する。 SELinuxを切る 変更

MongoDB 3の大きな変更点として、データを永続化するストレージ部分の実装が、 今まではOS任せのMMAPベースしか選べなかったのが、WiredTigerも選べるようになったことだ。 WiredTigerになって何がうれしいのかまとめてみた。 ドキュメントレベルロックになった MongoDB 2系ではMMAPベースでロックの単位がデータベースで、MongoDB 3系でも従来のMMAPベースのものだとコレクションレベルロックまでしかできないが、WiredTigerを選べばドキュメントレベルロックができるようになった。 これにより書き込み時のロック待ちが減る インデックスとデータを別ディレクトリにすることができるようになった --wiredTigerDirectoryForIndexesのオプションにより、インデックスをデータと別の場所に配置できる。メモリだけを高速なSSDに入れ、データは

2015年2月3日にMongoDB 3.0 がアナウンスされました。要約と所感をかきます。 MongoDB 3.0 アナウンス 要約 ストレージエンジンとして"WiredTiger"が導入される ドキュメントロックになり、書き込み性能7〜10倍UP ドキュメント圧縮が選べるようになり、最大80%圧縮 既存のmmapベースの仕組みも、ストレージエンジンも"MMAPv1"という名前になって改善される データベースロックからコレクションロックに変更 ジャーナルがよくなった ストレージエンジンAPIを設けた。 これによりWiredTigerとMMAPv1の二つをストレージエンジンを、同一レプリカ内に同居できる あたらしいストレージエンジンが出たらレプリカに追加して試すことができる ストレージエンジン開発プラットフォームとしてのMongoDB という考え方が生まれる。ストレージエンジンの開発者はアプ

MongoDBでは古いドキュメントを自動削除する機能として、キャップ付きコレクション(Capped Collections)とTTLインデックス(TTL Indexes)という二つの方法がある。 TTLインデックス(TTL Indexes) ドキュメントのあるdate型の値に、期間を指定してTTLインデックスを張ると、そのdateの値が指定期間よりも古くなった場合に自動的に削除する。 詳細 * date型のデータがないと使えない * 1分間隔で削除する（それより細かい間隔では削除できない） * 複合インデックスでは使えない * 削除はremoveクエリが発行される。そのため、指定期間通りにドキュメント消える事が保証される訳ではない。removeクエリが流れきるまではドキュメントは残る * 普通のインデックスと同様に検索クエリのときに使える キャップ付きコレクション(Capped Colle

CentOS 7でLVMディスク拡張するときに、ハマったことがあるので共有。 LVの拡張まで行って、最後にファイルシステムを拡張しようとするときに、CentOS 6の時代と同じくresize2fs とやると以下のエラー [root@localhost ~]# resize2fs /dev/centos/root resize2fs 1.42.9 (28-Dec-2013) resize2fs: Bad magic number in super-block while trying to open /dev/centos/root Couldn't find valid filesystem superblock. 調べていくと、CentOS 7 からデフォルトになっているXFSではresize2fsは利用できないということ。 XFSではresize2fs の代わりに xfs_growfs

MongoDBのMongoDBのメモリの使い方とプレヒーティングについて簡単に解説します。 前提はMongoDB ～2.6 on Linuxです。2.8の新しいストレージエンジン(wired tiger)ではこの話は関係ありません。 MongoDBのメモリ管理 まずMongoDBがどうやってメモリを管理しているかですが、 結論から言うとメモリは管理していません。 OSにすべてを任せています。具体的にはLinuxOSのmmap()というシステムコールを利用しています mmapとは？ mmapはファイルシステム上のファイルをメモリにマッピングして、プロセスからはメモリ上に乗せられたファイルの中身に高速にアクセスできる仕組みです。 プロセス起動直後にmmapでファイルをマップしても、最初は何もメモリには乗りません。 プロセスがファイルを読み取ろうとしたときに初めてメモリに乗せます。 その後はメモ

MongoDBには、MongoDB開発者御用達の便利ツール「mtools」というものがあるのですが、まだあまり知られていないようですので、紹介していきます。 mtoolsの概要 mtoolsはgithubで公開されており、 以下のコンポーネントが含まれます mlogfilter MongoDBのログファイルをマージして、スロークエリを探したり、フルスキャンを探したりできるツール。さらにログを属性でフィルタして、JSONにすることもできる。 mloginfo MongoDBのログファイルを食わせると、ログの開始時間、終了時間、バージョン、出してるバイナリ、各種イベント(リスタート、レプリカ関連)、クエリの種類などを集計してくれる。 mplotqueries MongoDBのログファイルを食わせると、グラフを作ってくれる mlogvis MongoDBのログファイルを食わせるとhtmlをはいて

fluentdのMongoDBプラグインを用いて、ログをMongoDBに入れる際に、 MongoDBの中のJSONをみると以下のように"time"のキーがなかった。 以下はApacheのaccess_logの例だが {"_id" : ObjectId("540eef3f0d094e535e000028"),"host" : "10.2.4.249", "user" : "-", "method" : "GET", "path" : "/elb_healthcheck.php", "code" : "404", "size" : "293", "referer" : "-", "agent" : "ELB-HealthChecker/1.0" }

1. MongoDBのサーバを直接インターネットにさらす ちゃんとFWの中に入れるなり、前にサーバを置くなりしよう。 2. アクセスコントロールをしない MongoDBにはロールベースアクセスコントロールがあります。これを使って、ユーザ毎にアクセスできるDBや操作を制御すべきでしょう。 3. SSLを使わない MongoDBドライバ - mongod(s)間をSSLしましょう。 4. 不必要なインターフェースを公開する HTTP,REST,JSONPインターフェースは使わないなら止めましょう。 5. ユーザのアカウント管理がずさん 2でアクセスコントロールを有効にしても、何でもできるユーザを作って使わせてはダメ。ちゃんと、最少な権限だけ与えましょう。 6. OSのパワーユーザで動かす Linuxならrootでmongodやmongosを動かすなってことです。 7. レプリカセットキーファイ

MongoDBの地理空間インデックス・クエリは結構複雑なので、整理してみました。 ドキュメントへの格納の仕方 地理空間データの格納の方法は以下の二通り 座標 GeoJSON

MongoDBで特に重要なOSの設定は以下の３つ ulimitを大きくする readaheadを小さくする NUMAをきる ulimitを大きくする 理由はTCPコネクションの枯渇を回避するため。 MongoDBはレプリケーションやシャーディングを使って、構成するコンポーネント(mongod,mongos,config)の数が多くなると、利用するTCPコネクション数がどんどん増えていく。 シングル構成であればあまり気にする必要はないかもしれない。 readaheadを小さくする 理由は物理メモリを効率よく利用するため。 readaheadはファイルをmmapでメモリにマップするときのサイズだが、このサイズが大きいとクエリで利用するドキュメント以外のデータもメモリにマップされてしまうことが多く、物理メモリが効率よく使えないことが多い。 MongoDBのresで表される物理メモリ利用量が、搭載

Pacemaker+DRBD+heartbeatでMySQLのクラスタ構成を作ってみる。 利用するパッケージは以下の通り。 CentOS 5.6 drbd83-8.3.12-2.el5.centos heartbeat-3.0.3-2.3.el5 pacemaker-1.0.12-1.el5.centos mysql-server-5.0.95-1.el5_7.1 各プロダクトのインストールはyumで出来るので割愛。基本的には公式HPをもとにして、いろいろ補足を入れていきます。 作る環境は以下の通り 共有IP「192.168.4.30」 にMySQLを立てる ノード「db1」 サービス用：eth1(192.168.4/24に接続) ヘルスチェック用：eth2(IP:192.168.5.31) ノード「db2」 サービス用：eth1(192.168.4/24に接続) ** ヘルスチェック用：

[徹底解説] MongoDBの監視やバックアップができるMMS(MongoDB Management Service)の使い方MongoDBMMS MMSの概要 MMSの機能 MMS(MongoDB管理サービス)はMongoDBの自動運用管理をしてくれるサービスであり、主に以下の機能があります。 監視 MongoDBの各種統計情報収集、グラフ化、監視 閾値を指定して超えたらアラートメール送付 バックアップ スナップショット取得・リカバリ 差分バックアップ ポイントインタイムリカバリ（時間指定リカバリ） オートメーション（2014/5現在、公開予定） 無停止バージョンアップ ワンクリック環境構築 MMSとMMSエージェントの役割分担 MongoDB単体ではMMSを利用できません。MMSエージェントを導入して、MMSと接続する必要があります。 MMSエージェントには監視を行う監視エージェントと