不幸福のエンジニアリング

私は悲観的な人間だ、ということに数時間前に気づいた。 そこまでの所以は、長い人生語りがあるので省略するとして、何より、これまで志していたエンジニアリングがその価値観に基づいていることに気づいたのだ。

ネット越しに聞く良いエンジニアリングとは「良いサービスを」「快適なUIを」「良質なユーザー体験を」などプラスのイメージを持った言葉で語られる。 どうも私はしっくりこなかったのだが、この日に私はとうとう「ユーザーの不幸をなくすこと」を優先的に考えるエンジニアであることに気づいた。

言葉にすれば「なんだ」と終わってしまうような気がするが、ここはひとつ私が体験したことを交えて不幸福を知るエンジニアリングについて持論を展開してみよう。

都営大江戸線清澄白河駅ホームの壁をご存じだろうか? ユニークなことに、工業製品のスクラップをぺしゃんこにして埋め込まれているのだ。

(参考) yaplog.jp

オシャレといえばそんな気がしてしまうが、数時間前の私はひどく悪いの印象を受けた。 元は恐らく立派だったであろう脚立が、見るも無残な姿に押しつぶされている。 それは効率的で意図があった形で、大小なりコストをかけて形にしたものが、台無しにされている。

「工業スクラップだから」と前もって説明を受ければ先入観が多少あったかもしれないが、何も聞かずの初見で目にした時はかなりショックだった。

これは誰かの意図とならないこと─不幸福を先に連想する私の意見だ。 発想の順序が違うかもしれないが、「これは幸福である」である前提でとらえるならば、このアートはどう見えるだろう?

見た目の重厚さやアートとして成立している、といった表面的な褒め方もあるが、「同じく元の形があった」という先ほどと同じ観点から、色々前向きな意見が出てこないだろうか。

前の形がつぶされている事実から、平面的でありながら立体として元の形が頭に活きる。 元の形があったからこその規則性、美しさが浮き出ている。

先ほどの私の頭からはこの言葉がひとかけらも出なかった。 (出たといえば、これも現代アートなんだな、と表面的な感想ぐらいだった) 本当に、私は悲観的だ。

この例えでの悲観的な捉え方は生産性の全くない話だが、 次の2つの捉え方ではどうだろう。

・今より良い機能を提供するのは、ユーザーにとっての幸福である ・より良い機能を提供できるのに今できないのは、ユーザーにとっての不幸である

命題では同じだ。 しかし、方向性でいえば、前者は発散し、後者は収束する。

エンジニア各位が何となく察する通り、目指す方向が違えば手にかけて形作る指向が生まれる。 幸福のためのエンジニアリングが謳う結果があれば、 不幸福を知るエンジニアリングが求める結果がある。

前置きが長くなってしまった。

前述の通り、私はどうやら不幸福を知るからこそできるエンジニアリングに長けている。 バグやユーザーが不快となる動線への嗅覚、 運用上の障害やプログラムを長期でメンテするうえでの問題点の予知。

これは、一般的に安定したソフトウェア開発で求められるベーシックな能力だが、 先ほどと同じように言い換えてみよう。

ユーザーがより良い体験をするための気づきと発想力、 メンテナンス性をより高める仕組みの提案力。

前者はやはり収束、後者は発散だ。

この手の話を巡って、よく本質は何だろう、と考える。 ネットには、よく幸福を謳うような情報が流れているが、そのほとんどが不幸からも語ることができて違う方向性を持ってしまうとすれば、では本質はどこにあるのか。

共通のインタフェースとする、ある事実のことをいうのだろうか。

だがおそらく、その本質を語る前に本稿で呼ぶ幸福のエンジニアリングと不幸福のエンジニアリングがある。 無形からアーキテクチャを提案するならば、その尚更だ。

20170310雑記(DB2とOracleの比較)

次の現場でDB2からOracleへの乗り換えをしたいという話を聞いて、そういえばOracleはちょっと触ったけどDB2ってよく知らないなーとういことで、色々調べまわる。

Oracleとは

  • Oracle社が提供するDBMS
  • 高い。1CPUあたり、5年で600万ぐらいのライセンス。
  • 内部実装が変態で、ガンガンメモリに情報をのせてロックをあの手この手で回避する。
  • 使い方が他のDBとかけ離れている。入り組んだ用途になると、メンテナンス可用性がだだ下がりに。

DB2とは

  • IBM社が提供するDBMS
  • Oracleに比べるとかなり安いが、それでもン十万/年もする。
  • 競合があると素直にロックして処理を止めたり、素直なインスタンス構成だったりする。
  • Oracleが1インスタンス特化に対して、DB2は機能の集約を避けて、分散DBの可用性を前提に立っているようだ。

比較1:参照一貫性保証

  • すごく長いトランザクションAがあったとする。そのトランザクションが走っている間、他の短かったりするトランザクションが必要なテーブルをいっぱい更新したりすると、SELECTを投げるたびになんか値が変わって、トランザクションAの処理が超面倒くさかったりする。その対策として「トランザクションAが開始したときの状態をとれるように値を保証する」メカニズムを参照一貫性保証と呼ぶ。

  • Oracle

    • 更新前データをメモリの中にとって、必要になったトランザクションにそいつをパスする。
    • 変態。
  • DB2

    • 参照ロック・占有ロックの法則に従い、素直に後から来た参照系をブロックする。
    • 要するに、滅茶苦茶にテーブル設計して参照・更新の密度あげちゃうとOracleに素で負ける。

比較2:インスタンスとDBの関係

比較3:レプリケーション(未完)

  • Oracle

  • DB2

    • PDFみた瞬間「あっ」ってすごく安心した。
    • oshiete.goo.ne.jp
    • Applyプログラムとやらにすべて集約する、Subscribeパターンみたいな感じなのかな?(適当)
    • チューニングできなさそうだけど使い方さえ誤らなければ大丈夫そう。(あと簡単そう)

DB2特有の機能

https://www.ibm.com/developerworks/jp/data/library/dataserver/pdf/session6_introduction.pdf

ワークロード

  • 処理をWORKLOADに分類して、優先度をつける仕組みみたいだ
  • うん・・・器用貧乏だよねぇ。

パーティション機能

  • つまり1インスタンスに複数DBインストールできる、というOracleメタなことをいっているっぽい。
  • クラスタってOracleに至っては複数層もあるがや。(知識として要求してくるところは違うが)
  • 複数に分散しても、リソース取りすぎとかで著しく性能劣化しませんよーと言っている気がする。

pureXML

  • XMLに特化したデータ型があるらしい。
  • インタフェース境界を越えてプログラム中に取り込んだデータモデルが何故取込前の形に・・・と拒絶間を覚えるもコンセプトは分かる。
  • が、明らかに人が変わりばんこに代わる長期運用に向かない。textにぶっこむのでは不満なのか?
  • あと、検索系とか何かのメタを保存するみたいな用途が考えられるものの、商用DBを用いるようなケースでは、スケーラビリティを考えると別途検索エンジンを使うべきじゃないのか・・・など色々突っ込みどころがある。

20170310雑記(DB2とOracleの比較)

次の現場でDB2からOracleへの乗り換えをしたいという話を聞いて、そういえばOracleはちょっと触ったけどDB2ってよく知らないなーとういことで、色々調べまわる。

Oracleとは

  • Oracle社が提供するDBMS
  • 高い。1CPUあたり、5年で600万ぐらいのライセンス。
  • 内部実装が変態で、ガンガンメモリに情報をのせてロックをあの手この手で回避する。
  • 使い方が他のDBとかけ離れている。入り組んだ用途になると、メンテナンス可用性がだだ下がりに。

DB2とは

  • IBM社が提供するDBMS
  • Oracleに比べるとかなり安いが、それでもン十万/年もする。
  • 競合があると素直にロックして処理を止めたり、素直なインスタンス構成だったりする。
  • Oracleが1インスタンス特化に対して、DB2は機能の集約を避けて、分散DBの可用性を前提に立っているようだ。

比較1:参照一貫性保証

  • すごく長いトランザクションAがあったとする。そのトランザクションが走っている間、他の短かったりするトランザクションが必要なテーブルをいっぱい更新したりすると、SELECTを投げるたびになんか値が変わって、トランザクションAの処理が超面倒くさかったりする。その対策として「トランザクションAが開始したときの状態をとれるように値を保証する」メカニズムを参照一貫性保証と呼ぶ。

  • Oracle

    • 更新前データをメモリの中にとって、必要になったトランザクションにそいつをパスする。
    • 変態。
  • DB2

    • 参照ロック・占有ロックの法則に従い、素直に後から来た参照系をブロックする。
    • 要するに、滅茶苦茶にテーブル設計して参照・更新の密度あげちゃうとOracleに素で負ける。

比較2:インスタンスとDBの関係

比較3:レプリケーション(未完)

  • Oracle

  • DB2

    • PDFみた瞬間「あっ」ってすごく安心した。
    • oshiete.goo.ne.jp
    • Applyプログラムとやらにすべて集約する、Subscribeパターンみたいな感じなのかな?(適当)
    • チューニングできなさそうだけど使い方さえ誤らなければ大丈夫そう。(あと簡単そう)

DB2特有の機能

https://www.ibm.com/developerworks/jp/data/library/dataserver/pdf/session6_introduction.pdf

ワークロード

  • 処理をWORKLOADに分類して、優先度をつける仕組みみたいだ
  • うん・・・器用貧乏だよねぇ。

パーティション機能

  • つまり1インスタンスに複数DBインストールできる、というOracleメタなことをいっているっぽい。
  • クラスタってOracleに至っては複数層もあるがや。(知識として要求してくるところは違うが)
  • 複数に分散しても、リソース取りすぎとかで著しく性能劣化しませんよーと言っている気がする。

pureXML

  • XMLに特化したデータ型があるらしい。
  • インタフェース境界を越えてプログラム中に取り込んだデータモデルが何故取込前の形に・・・と拒絶間を覚えるもコンセプトは分かる。
  • が、明らかに人が変わりばんこに代わる長期運用に向かない。textにぶっこむのでは不満なのか?
  • あと、検索系とか何かのメタを保存するみたいな用途が考えられるものの、商用DBを用いるようなケースでは、スケーラビリティを考えると別途検索エンジンを使うべきじゃないのか・・・など色々突っ込みどころがある。

diskfullのときの原因ドリリング

1日でつみあがったログファイル、ン十GB。しかもエラーログ。これシステムの脆弱性じゃないの?と思う一方、調査の仕方をメモ。

参考にしました。ありがとうございます

qiita.com

ディスクドライブ単位の使用状況を見る

df -h

-hは単位を適切に表示するオプション。

フォルダごとにディスク使用率を見る

ディレクトリやファイルへのアクセス権が必要なので root権限にしておく。

du -sh /var/log/*

-hは単位を適切に表示するオプション。 -sはファイルごとの詳細を表示するオプション。

怪しいディレクトリに潜っていき、再帰的に行って原因特定する。

【BIND】zoneファイルの更新メモ(TTL変更例)

zoneファイルの更新でいくつかハマった。 二度とないようにメモっておく。

やったこと

TTLの更新。例えばドメインやIP変更前にわざと短くして配布しておき、本変更をすぐに世界のDNSキャッシュに反映させるあれ。

zoneファイルの置き場

zoneファイルの置き場について。

場所は設定ファイルに記述されているんだけど、俗にいうchrootして設定ファイルの場所が変わっている場合がある。

chrootしているかどうかを見るには、bindの起動コマンドに-tオプションが付与されているかを見る。

ps aux | grep named

結果

named 643 0.0 0.9 30268 2336 ? S Jan05 0:07 /usr/sbin/named -u named -t /var/named/chroot

named.confの見方

見方といっても、変更に最低限必要なものだけ。

全体設定ファイルnamed.confは、デフォルトでは/etc/named.confに配置されている。 chrootしている場合、頭のパスにchrootしたパスをつけたものになる。

less /var/named/chroot/etc/named.conf

見るところは以下の通り。

directoryオプション

設定ファイル内に相対パスで記述したときに基準となるファイルパス。例によってchrootの影響を受ける。

options {
  ...
  directory "/var/named";
  ...
};

zoneオプション

ゾーン情報の設定。 ドメインとゾーンファイルが指定。ゾーンファイルパスは例によってdirectoryオプションとchrootの影響を受ける。

ちなみに、type slave;が記述されている場合、プライマリDNSから設定がtransferされるようになっているはずなのでゾーンファイル変更不要。

options {
   ...
   zone "hoo.var.com" {
     type master;
     file "hoo.var.com.zone";
   }
   ...
};

zoneファイルの変更

以下を変更。

1) TTLを短くする。以下、例。

$TTL  8H

;$TTL  8H
$TTL  600 ; 10 minutes

2) serialをあげる

一般的には、変更日のYYYYMMDD + 連番2桁 として管理を楽にする。

 2015112801

 2017022601

serialが新しくないと、reloadしても設定を読み込んでくれない。 戻し作業で再変更する場合は、連番を上げたバージョンを用意する。

 2017022602

3) minimumの変更

仮にDNSサーバーが落ちて解決不能となったときに、落ちてるから問い合わせても無駄だよ期間を指定する Negative-TTL の値。 別にTTLの2倍程度だったら問題ないんだけど、それ以上だと復旧しているのにキャッシュに残ったせいで復旧が遅れることがあるらしいので、変更しておく。

あと、いつの時代の基準化わからねど、普通はTTLと同じにするそうだ。(大手サービスでDNSサーバーに余力のあるところは数秒とかに設定しているとこも多いそう。)

8H  ; minimum

600  ; minimum

設定ファイルの上書きとリロード

rootじゃないと操作できないから気を付けてね。

設定ファイルを上書きする

設定ファイルを上書きする。

  • ファイルパスの完全一致
  • 権限の完全一致
  • ファイルのタイムスタンプが前設定ファイルより新しい(重要)

※言うまでもなくだけど、cp -ipでちゃんとバックアップとってね

ゾーンファイルの確認

named-checkzone "hoo.var.com" /var/named/chroot/var/named/hoo.var.com.zone

OKが出力されたらエラーなし。

named-confの確認

chrootしているときは -t オプションを使う。

以下、chrootしながら/var/named/chroot/etc/named.conf をチェックする例。

named-checkconf -t /var/named/chroot /etc/named.conf

何も出力されなかったらエラーなし。 これはnamed.confのチェックしかしないので注意。

-z オプションでゾーンファイルのチェックもできるけど、正常メッセージでもわっと出たときに初見びびるかも。

リロード

rndc reload

確認

自分に向けてdig。SOAレコードと正引きの2つともテストする。

dig @127.0.0.1 hoo.var.com

色々いっぱい出るけど、 ;;AUTHORITY SECTION: にserialとminimumが載ってればOK。

dig @127.0.0.1 www.hoo.var.com

こちらは、 ;; ANSWER SECTION:TTLつきで正引きの結果が表示される。

以上

メモおわり。

chrootと、zoneファイルのタイムスタンプが罠だった。 bind以外のDNSサーバーだとどうなのかな。