Ubuntu から PostgreSQLをアンインストール

作業メモ PostgreSQLのアンインストール

UbuntuPostgreSQLをインストールした場合

UbuntuのAPT*1PostgreSQLをインストールすると、一般的なデータベースクラスタ内のフォルダ構成にならない。

/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件を超えるケースが発生した。

 

そもそも1秒あたりに10000件を超えるリクエスト投げまくる処理はいかがなものか、ということで、実装自体を見直すことにした。

 

見直し案

1) 処理すべきデータをある程度まとめて(バルクにして)投げる

2) フロントアプリがJSONデータを作って投げず、制御用APIをたたくようにする。
   元データファイルをアップロードし、ETL*1処理を

   キックするAPIを用意する。

 

データ量が今後増える可能性も考慮して、案2を採用した。

これにより、もともと処理が遅いといわれていたのも改善され、みんなハッピーに。

 

go on developing...

 

参考

 

*1:Extract Transform Load

マイクロサービスアーキテクチャ 2章 進化的アーキテクト(2)

進化的アーキテクトの主な責務

 

1.ビジョン

 顧客や組織の要件を満たすシステムの技術ビジョンを明確に伝える。

 以下のチェックポイントを確認するとよい。

  1. 戦略的目標は明確か? ・・・ 要件の方向
  2. 原則が存在しているか? ・・・ 達成手段の原則
    監視:システム全体の健全性ビューが作成できる
    インタフェース:技術、プロトコル、バージョニングなど
    アーキテクチャの安全性:規則に正しく従ってサービス構築されている
  3. ラクティスが選定されているか? ・・・ 技術的な側面

 サービス実装例のドキュメントやカスタムのサービステンプレート(ノーコードのサービス構築など)は、「原則」構築に有益。

2.共感

 顧客や同僚に対する自分の判断の影響を理解する。

 

3.協調

 できるだけ多くの仲間や同僚と関わり、ビジョンの定義、改良、実行に役立てる。

 

4.適応性

 顧客や組織の要求により技術ビジョンを変更する。

 技術ビジョンの変更に伴い、「技術的負債」が発生する。

「技術的負債」は、実世界の負債と同様に「短期的な利点

はあるが、長期的にはコストとなる」技術をさし、継続的にみたときデメリットとなるものを指す。

 これは「原則」的に採用されないはずだが、「例外処理」として採用される、または技術ビジョンの変更に伴い、更新されなかった場合には、負債ログとして残し、定期的に見直す運用体制を作る。

5.自律性

 チームに対して標準化と自律性の実現との間の適切なバランスを見出す。

 

6.ガバナンス

 実装しているシステムを技術ビジョンに合わせる。

COBIT(Control Objectvies for Information and Related Technology、情報関連技術のコントロール目標)がとても優れた定義をしています。

 

ガバナンスは、利害関係者のニーズ、状況、選択肢を評価し、優先順位付けと意思決定を通じて方向性を設定し、合意した方向性や目的に対する実績、順守、進捗の監視を行うことで企業の目的が達成されるようにすることです。

                           ――COBIT5

 

go on developing... 

 

続きを読む

マイクロサービスアーキテクチャ 2章 進化的アーキテクト(1)

2章 進化的アーキテクト

進化するアーキテクト象

アーキテクトという言葉についての言及。

私たちは、自分自身を「ソフトウェアエンジニア」や「ソフトウェアアーキテクト」と呼びます。しかし、全然違いませんか?

システム開発の業界は発展途上で、そもそも建築業界における建築士(アーキテクト)のように過去数千年に及ぶ知識体系に裏付けされた厳密や規律、社会における重要性の認知度などが比べ物にならない。IT「アーキテクト」は、自分が何者であるかを説明するために、他の業界から言葉を借りて表現しているに過ぎない

 

ソフトウェア開発では、建物の設計や建設を行う場合よりも、急に要件が変更されます。

(中略)

ソフトウェアが顧客の手に渡っても、ソフトウェアは不変の成果物ではなく、私たちが対応し適応していかなければならないものだと、受け入れなければなりません。そのため、アーキテクトは完璧な最終製品を作成するという考え方を変え、代わりに適切なシステムが得られるようなフレームワークを作成することを重点に置き、さらに学んで成長を続ける必要があります。

 

ITアーキテクトはの役割は、都市計画家のように多数の情報源を調べ、将来の用途も考慮して現在の利用者のニーズに最も合うようにサービスの配置(区画)を最適化すること

 

したがって、アーキテクトが注意すべきは、区画で起こること > 区画で起こること。つまり、サービスの境界とそのインタフェースが重要事。

 

go on developing...

 

続きを読む

マイクロサービスアーキテクチャ 1章 マイクロサービス

マイクロサービスについて、過去に調べた内容をまとめる

マイクロサービスについて、過去に調べた内容を「はてな」に集約させることにした。

そういうわけで、手始めに『マイクロサービスアーキテクチャ』を読んだ内容を移植する。

 

1章 マイクロサービス

マイクロサービスは、協調して動作する小規模で自律的なサービスです。

  → SOA(Service-Oriented Architecture)の実現手法。

基本思想は「小さく、かつ1つの役割に専念」

 凝集性を高めることが重要

 単一責任原則:変更する理由が同じものは集める、変更する理由が違うものは分ける

f:id:GearDolls:20201224215148p:plain

 

「何をどの程度小さくすれば良いのか?」

 

何を?:コード行数?コンポーネント*1、サイズ?

どの程度?:大きいと感じなくなるまで・・・「開発チームに依存する」!!
 指標として

RealEstate.com.auのJon Eavesは、マイクロサービスを「2週間で書き直せるもの」と特徴付けています。

 

コンポーネント分離の黄金律

 他には何も変更せずに、単独でサービスの変更やデプロイを行える

 

 

go on developing...

*1:『Code Complete 第2版 完全なプログラミングを目指して』では、デプロイ可能な単位だと説明があった(気がする)。

続きを読む

.NET 5 で Open API ( Swagger )の開発(1)

VS Codeで.NET 5 のOpen API アプリを開発するための環境準備

開発フォルダに移動後、Terminalを開く。

 

web api 用のテンプレートプロジェクトをリストア。

 

f:id:GearDolls:20201223225451p:plain


OpenAPIの開発には、Swashbuckleを採用。NSwagを選ばなかった理由は、NSwagが2020年12月24日時点でVS Codeに対応していなかったから。

 

パッケージインストール。

 

f:id:GearDolls:20201223230026p:plain

 

勝手にStartupやProgramがSwashbuckle向けに書き換わっていたので、何も考えずにdebugを走らせてみる。何やら出てきた。

64ビットのプロセスのみをデバッグできます。

f:id:GearDolls:20201223230944p:plain

もしや、と思って確認したらSDKがx84になっていた。脳死状態で作業してると実感。

 

x84のSDKをアンインストールして、x64のSDKをインストールする。

 

その後、再度debugを実行。

 

f:id:GearDolls:20201223231531p:plain

f:id:GearDolls:20201223231601p:plain

 

おー、起動してる。

動作の確認に移る。

f:id:GearDolls:20201223231813p:plain

f:id:GearDolls:20201223231845p:plain

 

中の実装(特にController)は変わっていない。

ということは、OData*1のパッケージみたいに、クエリパラメータに対する処理を自動で実装してくれるパッケージではないのか…

 

GraphQLも検討しといた方が良さそうだな。 

 

go on developing... 

 

*1:Open Data Protocol

続きを読む

Visual Studio Codeで.Hello World on .NET 5

VS Codeで.NET 5 のアプリケーション開発するための環境準備

f:id:GearDolls:20201223222732p:plain

 

開発フォルダに移動後、Terminalを開く。

 

f:id:GearDolls:20201223223000p:plain

 

dotnet sdkがインストールされていないので、インストールする。

 

ダウンロード元は、Download .NET 5.0 (Linux, macOS, and Windows) (microsoft.com)

 

f:id:GearDolls:20201223223420p:plain

 

インストーラをダウンロード後、VS Codeを再起動して、確認。

 

f:id:GearDolls:20201223223652p:plain

 

成功しているので、次。 C#をインストール。

 

 

f:id:GearDolls:20201223223823p:plain

 

C#Hello World

 

f:id:GearDolls:20201223224048p:plain

f:id:GearDolls:20201223224136p:plain

 

go on developing...