年収1000万円を要求するインフラエンジニアが知っておくべき最低限のLinuxディストリビューション - Qiita
はじめに なんか某所に面接に来た年収1000万円以上希望のインフラエンジニア候補に、Linuxのどのディストロ使ってるか聞いたら「ディストロってなんですか？」と聞き返して来たという話をきいたのでオラびっくらこいてQiitaに記事書き始めちまったぞ。 使ったことはなくてもいいから名前と特徴くらいは知っていて欲しいディストリビューションを列挙する。ディストロの系列ごとに書いたので、列挙順は重要度順ではない。が、2019年現在絶対に知ってないとマズイalpineだけは先頭に置いた。 busybox系 Alpine Linux 公式: https://www.alpinelinux.org/ Wikipedia: https://ja.wikipedia.org/wiki/Alpine_Linux パッケージマネージャー: apk 最小構成だと約5.6MBという圧倒的小ささで、dockerコンテナ
Java のバージョンを上げるだけで、プログラムは速くなるのか - Qiita
（この記事は 地平線に行く とのマルチポストです） よく Java の実行バージョンを上げるだけで速くなるという話を聞きます。 でも、本当にそうなのでしょうか。また、本当だとしたらどれぐらい速くなるのでしょうか。 そこで、簡単なプログラムで実験してみました。 実験概要 実験用に、数独を解く Java のプログラムを作成しました。 このプログラムは単純な演算を繰り返し行ってるだけなので、Webアプリケーションのような複雑なプログラムとはおそらく傾向が違いますが、参考程度にはなるかなと思います。 これをJava 1.1 でコンパイルし、Java 1.1 ～ 12 の各 Oracle JDK (32bit/64bit) で数独100万問のデータセットを読み込んで解き終わるまでの時間を測定しました。1 細かい測定条件は以下の通り。 実行環境 Windwos 10 Home 1809 (64bit)
keepalive_requests in upstream context - Qiita
先日、某所のnginxを1.14系から1.16系に更新したところ、レスポンスタイムが悪化する現象に遭遇したので、その時の対処記録。以下は99percentileと95percentileでのレイテンシのグラフ。 99percentile latency 95percentile latency nginxのバージョンアップでレスポンスタイムが悪化するのを経験したのは初めてのことだったのですが、いろいろ調べてみるとアップストリームサーバとのキープアライブに関する挙動が大きく変わったのが原因で、そのへんのディレクティブの値をちょいと調整することで元のレスポンスタイムを維持できるようになりました。 nginxの1.16系と1.14系の大きな違いの一つとしてkeepalive_requestsディレクティブが従来のhttp, server, locationコンテキストに加えてupstreamコン
sourceコマンドを誤って使ってしまいゾッとした話 - Qiita
ってやってしまった。 ぎゃぁぁあああああああーーーーーーーー！！！！！！！！ と叫んでも遅し、、、処理が走ってしまい止められなくなってしまいました。 処理の途中に 「公開鍵を上書きするかどうか？」とか出てきて、 n として回避した後、今は無くなっているレポジトリから git clone しようとしたところで、アカウント確認のために処理が止まり、そこで、 Ctrl + c で強制終了できました。 解説 source コマンドは、ファイルに書かれたコマンドを現在のシェルで実行するコマンドです よって、私がミスして実行してしまった処理の内容は、 .zsh_history にファイルに書かれたコマンドが1行ずつ実行する。という内容になります。 .zsh_history には私が過去に打ったコマンドがすべて記録されているため、つまり、それらのコマンドが順に実行されていくということになってしまいます。
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
Postgresql サーバを移行したらAUTO VACUUM が実行されず、データベースが肥大化した時の話 - Qiita
Postgresql サーバを移行したらAUTO VACUUM が実行されず、データベースが肥大化した時の話PostgreSQL Postgresqlデータベースの引越しを検討されている方や、引越し後にデータベースの肥大化に悩まされている方の参考になればと。 What happened Live環境のPostgresqlデータベースの引越しを行って数週間後、Postgresqlのdata volumeがこれまでにない異常なペースで消費されていることに気付く。 Drill down record数の増加状況は移行前後で特に大きな違いはない。 Liveのデータベースを定期的にstaging環境にrestore (+ データのクレンジング) しているが、staging環境と比較しても明らかに大きなサイズになっている。stagingにrestoreすると15GB程度のテーブルが、liveでは100
Dockerでデバッグ対象のコンテナにツールを入れずにtcpdump/straceなどを使うワンライナー - Qiita
はじめに Dockerであんなコンテナやこんなコンテナを動かしてると、なんかうまく動かなくて、デバッグのためにtcpdumpとかstraceなどのツールが使いたくなることが稀によくあります。 そんな時、デバッグ対象のコンテナ内にツールを一時的にインストールしちゃうというのが、まぁ簡単で分かりやすいんですが、デバッグ対象のコンテナを汚すのはできれば避けたいところです。 Dockerのコンテナの分離というのは、結局のところLinuxのリソースの名前空間の分離であるので、逆に同じ名前空間を共有すれば、デバッグ用に立てた隣のコンテナから、デバッグ対象のコンテナのネットワークやプロセスの状態を観察することも可能です。 また、docker buildはDockerfileを標準入力から受け取ることもできるので、ワンライナーにしてデバッグ用のコンテナをシュッと呼び出せるようにしてみました。 TL;DR
Linux メモリ管理を理解したい - Qiita
Linux カーネルのメモリ管理方法について、勉強したことをまとめる。 メモリ管理はハードウェアに強く依存するため、x86_64 かつ OS起動後に 64bitプロテクトモード に移行したあとに話を絞る。また、OS は CentOS7.6、カーネルは次のバージョンを利用する。 ]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 概要 ノイマン型アーキテクチャ コンピュータの基本的な構成のひとつ。次の図が参考になる。 ほぼ全てのコンピュータが、このアーキ
データベースにRDBを選択するときの注意事項について考える（追記あり） - Qiita
2019年6月20日追記： この度は、本ブログにて技術的に誤った記事を掲載したことをお詫び申し上げます。具体的には以下の通りです。 一方的にRDBがスケールしないという技術的根拠が薄い内容となっていました。 RDBとAmazon DynamoDB（以下、DynamoDB）/NoSQLデータベースを要件に応じて適切に選択するという内容になっていませんでした。また、本来考慮すべきアプリケーションの設計やデータアクセスパターンに言及しておらず、RDBのデメリットの部分にのみ焦点を当てる内容となっていました。 DynamoDBの具体的な活用やDynamoDBを使う上での注意点についても触れられていない不明瞭な記載でした。 当初の記事の目的としましては、特定のユースケースをサンプルとして、最適なデータベースを選択頂くことでした。近日中に正確な技術記事を掲載させて頂きます。 以下の内容は修正前の内容と
2019年のワークフローエンジンまとめ - Qiita
概要 データパイプラインの管理にワークフローエンジンを導入したいのですが、今の要件に対してどれが合っているのか判断しきれない部分があるので整理してみました 最近の導入事例や発表をみるかぎりAirflow, Argo, Digdagあたりが人気なのかなと思います ワークフローエンジンとは ワークフローエンジンとは定期的なバッチ処理をうまく処理できるように、バッチ実行を管理してくれるソフトウェアのことです 古典的な実現方法としては適当なlinuxサーバーの上でcron実行させることが考えられますが、以下のような問題があります ジョブごとの依存関係を表現できない。cronの時間指定で実現させようとすると、タスクAを１時に開始してそれが完了するとみなして依存するタスクBを２時に開始するというような書き方をすることになるが、実際にタスクAが２時までに終わらなかった場合に処理が上手く実行できない タス
ログを gzip で圧縮しているなら zstd を導入しよう - Qiita
はじめに zstd コマンド(zstdless, zstdcat, unzstd なども)は gzip にも対応しています。特にデコードは拡張子を見て自動で gzip と zstd を切り替えてくれるので、 gzip 圧縮されたログと zstd 圧縮されたログが混在している環境でも透過的に扱うことができます。 なので gzip から zstd への切り替えは次のように段階的に進めることができます。 zstd コマンドツール群のインストール 圧縮されたログを扱うときに zstd を使い始める 圧縮フォーマットを zstd に切り替える 性能比較 Debian 9.3 で gzip 1.6 (aptでインストールしたもの) と zstd (1.4.0) を比べてみます。 対象となるファイルは ltsv でゴチャゴチャとアプリの情報を混ぜた重めの apache のアクセスログです。 (5,367
Gatling の exec メソッド内の記述方法と、Sessionの扱い方のまとめ - Qiita
概要 Gatlingのテストコードを記述するためにはexec内の書き方とSessionの扱い方を覚えなければいけません。 どれも http://gatling.io/docs/2.1.7/index.html に記述されていることですが、 日本語で記載された記事が少ないので、全てではありませんが簡単にまとめました。 チュートリアルを実行できたレベルの人が見ることを想定してまとめています。 ※この記事は、「Gatlingで何が出来るか」ではなく、「Gatlingのメソッドの使い方やコードの書き方」の視点より書いています。 複数のexec処理を実行する execをメソッドチェーンで記述する execが複数ある時の一番シンプルな書き方です。Gatlingのサンプルにも記述されてます。 val search_exec = exec(http("Home")) .exec(http("Search"
数時間で完全理解！わりとゴツいKubernetesハンズオン！！ - Qiita
社内でKubernetesハンズオンをやってみたのでおすそ分け。 参加者6人からバンバン出てくる質問に答えながらやって、所要時間4時間ほどでした。 SpeakerDeckにも資料を上げています。 https://speakerdeck.com/ktam1219/yaruze-kuberneteshanzuon (2019/07/11追記) 続編書きました！ -> 今度はあんまりゴツくない！？「わりとゴツいKubernetesハンズオン」そのあとに ハンズオンの目標 Kubernetesとお友達になる イメージを掴む 触ってみる(ローカル・EKS・ちょっとGKE) 構築・運用ができるような気分になる 巷にあふれるKubernetesの記事・スライドが理解できるようになる EKSがメインになっているのは、会社の業務でAWSを使うことが多いからです。 純粋にKubernetesを勉強したいだけな
Amazon Linux 2 に snoopy logger をインストールする - Qiita
docker run -it library/amazonlinux:2 /bin/bash yum install -y gcc gzip make socat tar wget autoconf git libtool m4 yum install -y which rm -f snoopy-install.sh wget -O snoopy-install.sh https://github.com/a2o/snoopy/raw/install/doc/install/bin/snoopy-install.sh chmod 755 snoopy-install.sh ./snoopy-install.sh git-master bash-4.2# ./snoopy-install.sh git-master SNOOPY INSTALL: Required programs alre
【AWS】API GatewayからLambdaを非同期で実行する - Qiita
はじめに 最近Web APIを素早く用意するためにAWSのAPI Gateway + Lambdaの構成をよく使います。 しかし、サービスの質の向上や、仕様のためAPIはレスポンスを早く返さなければならない場合が多々あります。 ネットで検索すると、API GatewayからInvocationTypeを指定してLambdaを非同期呼び出しする事で先にレスポンスを返してしまう話はよく出てきますが、Lambda側で必要な処理が書かれていない事が多く、大抵のテストコードではプロセスをキルされてしまい、Lambdaが処理を停止します。（今回はNode.jsの記事なので、Pythonなどでは必要ないのかも？） なので設定例を自分用備忘録的に書き残しておきます。 画像が多くて見辛いかもしれません。 処理の流れ API Gatewayがリクエストを受け取る 非同期でLambdaを呼び出す Lambdaか
0.0.0.0にはアクセスしないこと - Qiita
はじめに この記事は2019年4月時点で調べたものをベースにしています。将来的に変わるかもしれません。 tl;dr 0.0.0.0を宛先に使うのは誤り ただしOSによっては 127.0.0.1 に到達するので支障がなかったりする 想定読者 0.0.0.0と127.0.0.1の違いをすぐに答えられない人が対象です。 ネットワークな人はわかっていることだと思うのでブラウザバックしてもらって構いません。 強い人は間違えているところコメントください。 環境 Ubuntu 16.04を利用します。 $ uname -a Linux parallels-vm 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 簡単な例 Webの文脈ではWebサーバのQu
SVN リポジトリの特定のディレクトリから Git リポジトリを作る - Qiita
SVN から Git に移行する際、ログを残したまま移行する場合に git svn コマンドを使うと思いますが、一つのリポジトリに複数のプロジェクトがディレクトリで分けて入っていたので特定のディレクトリの中身だけ取り出す必要がありました。 以下のように trunc, branches, tags にそれぞれ同じディレクトリ名を指定するとそのディレクトリ内から Git リポジトリを作成することができます。 git svn clone http://<サーバーのドメイン>/<リポジトリのパス> --trunk="<ディレクトリ名>" --branches="<ディレクトリ名>" --tags="<ディレクトリ名>" --username="<SVN のユーザー名>"
Gitはどうやってテキストファイルとバイナリファイルを自動識別しているのか？ - Qiita
tl;dr 先頭 8000 バイト以内に NUL が有ったらバイナリファイル。 Gitの実装 Gitの内蔵diffは FIRST_FEW_BYTES だけ検索するようになっている。 https://github.com/git/git/blob/6e0cc6776106079ed4efa0cc9abace4107657abf/xdiff-interface.c#L187 #define FIRST_FEW_BYTES 8000 int buffer_is_binary(const char *ptr, unsigned long size) { if (FIRST_FEW_BYTES < size) size = FIRST_FEW_BYTES; return !!memchr(ptr, 0, size); }
Amazon Elastic Container Service for Kubernetes (EKS)の所感 - Qiita
ついにAWSのマネージドKubernetesサービス「EKS」が発表されましたね！ この記事では、これまでKubernetes on AWSに取り組んできた @mumoshu の観点でEKSについてまとめてみたいと思います。 @mumoshuって誰？ Kubernetes Incubatorのひとつ、kube-awsというKubernetesクラスタのプロビジョニングツールのメンテナです。 Kubernetes on AWSのつらみ これまでKubernetesをAWSで運用する場合の最も大きなつらみ（と思われていた）は、Kubernetesを自前でAWSにデプロイすることでした。 例えば、AzureやGCPにはそれぞれAKSやGKEといったKubernetesのマネージドサービスがあります。 AKSやGKEは「クラスタを作成する」という操作をすればKubernetesが使い始められたり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Linux2とAmazon Linuxの違いについて（メモ） - Qiita
