OSS-DB Goldの出題範囲
出題範囲は公式サイトを確認
出題される区分としては、以下の4区分みたいです。
- 運用管理
- 性能監視
- パフォーマンスチューニング
- 障害対応
学習時間は２週間～１ヶ月とあるけれど、１日何時間勉強できると想定してなんでしょうね。
ゆっくり勉強できる時間がなかなか取れない身としては、1ヶ月で取れるのかなあ、と不安です。
頑張るしかないですね。
PostgreSQLのスペシャリストへ
ITスキルは色々必要
IT組織の規模が小さな会社にいると、フルスタックなITスキルが必要になってくるなと感じています。
これまで「このスキルほしいな」と思ったものは勉強してきたつもりですが、やはり広く浅くな状態なので、もう一歩進みたいと思います。
次のターゲットはOSS-DB Gold
数年前にOSS-DB Silverは取得していたのですが、Goldは「別にいますぐPostgreSQLは使わないし、いいか」と放置していました。
しかし、ここ数年でメインで扱うでDBがOracleからPostgreSQLに変わり、スキル不足を実感しています。いつも「これでいいのかな、問題ないのかな」と不安になってしまう状態になってしまっているのです。
OSS-DB Goldを取得したとしても、それは変わらないのかもしれませんが、その場その場で調べて対処するというようなやり方や、「ひとまずこれでいいか」と知識不足の状態で進めてしまうよりは、良い方向に向かうのではないかと期待しています。
OSS-DB Goldは教科書や問題集が極端に少ない
数年にも感じていたことですが、この状態は変わらずようですね。
待っていれば出版されるかな、と思っていたのですが。
Linuc レベル２を受験して感じたことですが、参考書を信じすぎるのは良くないかもしれません。
「参考書をしっかりやったから、ここにあることはバッチリ」でも、試験を出しているのは、参考書を作っている人たちではないのですよね。当たり前ですけど。
公式サイトベースで勉強するしかない
そういうわけで、公式サイトベースで自分なりのやり方でOSS-DBにチャレンジしてみようと思っています。
どのような結果になるか楽しみです。
Ubuntu から PostgreSQLをアンインストール
作業メモ PostgreSQLのアンインストール
UbuntuにPostgreSQLをインストールした場合
UbuntuのAPT*1でPostgreSQLをインストールすると、一般的なデータベースクラスタ内のフォルダ構成にならない。
/etc/や/var/などにデータベースクラスタ内の各種ディレクトリが分散配置される。
PostgreSQLのDocなどでは、以下のような構成で説明されることが多い。
データベースクラスタ ┳ base
┣ pg_commit_ts
略
┣ pg_hba.conf
┗ postgresql.conf
さらにバージョンアップするとより複雑に
バージョンアップを行うと、/etc/postgresql/main/{バージョン}/のフォルダが複数でき、さらにそれぞれのバージョンでプロセスが起動する。
それくらいバージョンアップのスクリプトで何とかしてくれよ、と思う。
そんなこんなで、色々といじりまわした結果、一度まっさらにしたくなった。
実際の作業はコマンド一つ
$sudo apt-get purge postgres*
go on developing...
*1:Advanced Package Tool
Kong API のRate-Limitingに引っかかった件
あるサービスを本番展開した後、しばらくして「データ更新ができない」というインシデントが発生した。
調べてみると、API GWとして導入しているKong APIを中継すると処理が失敗していることがわかった。
その時のエラーがこれ。
json is {
"message" : "An unexpected error occurred"
}
. response is StatusCode: 500, ReasonPhrase : 'Internal Server Error',
Version: 1.1, Content: SYstem.Net.Http.HttpConnectionResponseContent,
Headers:
{
（中略）
,X-RateLimit-Limit-Second: 10000,
,X-RateLimit-Remaing-Second: 9999
,RateLimit-Remaing: 9999
,ReteLimit-Limit: 1000
（中略）
}
確認すると、Rate-Limitingを10000 requests per 1 secondで設定していた。
評価期間中は処理データ量が10000件未満でやっていたが、運用開始後10000件を超えるケースが発生した。
そもそも１秒あたりに10000件を超えるリクエスト投げまくる処理はいかがなものか、ということで、実装自体を見直すことにした。
見直し案
１） 処理すべきデータをある程度まとめて（バルクにして）投げる
２） フロントアプリがJSONデータを作って投げず、制御用APIをたたくようにする。
元データファイルをアップロードし、ETL*1処理を
キックするAPIを用意する。
データ量が今後増える可能性も考慮して、案２を採用した。
これにより、もともと処理が遅いといわれていたのも改善され、みんなハッピーに。
go on developing...
参考
*1:Extract Transform Load
マイクロサービスアーキテクチャ ２章 進化的アーキテクト（２）
進化的アーキテクトの主な責務
１．ビジョン
顧客や組織の要件を満たすシステムの技術ビジョンを明確に伝える。
以下のチェックポイントを確認するとよい。
- 戦略的目標は明確か？ ・・・ 要件の方向
- 原則が存在しているか？ ・・・ 達成手段の原則
監視：システム全体の健全性ビューが作成できる
インタフェース：技術、プロトコル、バージョニングなど
アーキテクチャの安全性：規則に正しく従ってサービス構築されている - プラクティスが選定されているか？ ・・・ 技術的な側面
サービス実装例のドキュメントやカスタムのサービステンプレート（ノーコードのサービス構築など）は、「原則」構築に有益。
２．共感
顧客や同僚に対する自分の判断の影響を理解する。
３．協調
できるだけ多くの仲間や同僚と関わり、ビジョンの定義、改良、実行に役立てる。
４．適応性
顧客や組織の要求により技術ビジョンを変更する。
技術ビジョンの変更に伴い、「技術的負債」が発生する。
「技術的負債」は、実世界の負債と同様に「短期的な利点
はあるが、長期的にはコストとなる」技術をさし、継続的にみたときデメリットとなるものを指す。
これは「原則」的に採用されないはずだが、「例外処理」として採用される、または技術ビジョンの変更に伴い、更新されなかった場合には、負債ログとして残し、定期的に見直す運用体制を作る。
５．自律性
チームに対して標準化と自律性の実現との間の適切なバランスを見出す。
６．ガバナンス
実装しているシステムを技術ビジョンに合わせる。
COBIT（Control Objectvies for Information and Related Technology、情報関連技術のコントロール目標）がとても優れた定義をしています。
ガバナンスは、利害関係者のニーズ、状況、選択肢を評価し、優先順位付けと意思決定を通じて方向性を設定し、合意した方向性や目的に対する実績、順守、進捗の監視を行うことで企業の目的が達成されるようにすることです。
――COBIT５
go on developing...
続きを読む
マイクロサービスアーキテクチャ ２章 進化的アーキテクト（１）
２章 進化的アーキテクト
進化するアーキテクト象
アーキテクトという言葉についての言及。
私たちは、自分自身を「ソフトウェアエンジニア」や「ソフトウェアアーキテクト」と呼びます。しかし、全然違いませんか？
システム開発の業界は発展途上で、そもそも建築業界における建築士（アーキテクト）のように過去数千年に及ぶ知識体系に裏付けされた厳密や規律、社会における重要性の認知度などが比べ物にならない。IT「アーキテクト」は、自分が何者であるかを説明するために、他の業界から言葉を借りて表現しているに過ぎない。
ソフトウェア開発では、建物の設計や建設を行う場合よりも、急に要件が変更されます。
（中略）
ソフトウェアが顧客の手に渡っても、ソフトウェアは不変の成果物ではなく、私たちが対応し適応していかなければならないものだと、受け入れなければなりません。そのため、アーキテクトは完璧な最終製品を作成するという考え方を変え、代わりに適切なシステムが得られるようなフレームワークを作成することを重点に置き、さらに学んで成長を続ける必要があります。
ITアーキテクトはの役割は、都市計画家のように多数の情報源を調べ、将来の用途も考慮して現在の利用者のニーズに最も合うようにサービスの配置（区画）を最適化すること。
したがって、アーキテクトが注意すべきは、区画間で起こること ＞ 区画内で起こること。つまり、サービスの境界とそのインタフェースが重要事。
go on developing...
続きを読む
マイクロサービスアーキテクチャ １章 マイクロサービス
マイクロサービスについて、過去に調べた内容をまとめる
マイクロサービスについて、過去に調べた内容を「はてな」に集約させることにした。
そういうわけで、手始めに『マイクロサービスアーキテクチャ』を読んだ内容を移植する。
１章 マイクロサービス
マイクロサービスは、協調して動作する小規模で自律的なサービスです。
→ SOA（Service-Oriented Architecture）の実現手法。
基本思想は「小さく、かつ１つの役割に専念」
凝集性を高めることが重要
単一責任原則：変更する理由が同じものは集める、変更する理由が違うものは分ける
「何をどの程度小さくすれば良いのか？」
どの程度？：大きいと感じなくなるまで・・・「開発チームに依存する」！！
指標として
RealEstate.com.auのJon Eavesは、マイクロサービスを「2週間で書き直せるもの」と特徴付けています。
コンポーネント分離の黄金律
他には何も変更せずに、単独でサービスの変更やデプロイを行える
go on developing...
*1:『Code Complete 第2版 完全なプログラミングを目指して』では、デプロイ可能な単位だと説明があった（気がする）。
