ラベル 可用性 の投稿を表示しています。 すべての投稿を表示
ラベル 可用性 の投稿を表示しています。 すべての投稿を表示

2022年3月26日土曜日

会計ソフトが動かなくなった!

令和3年度の確定申告無事終わったでしょうか。私は年末年始に個人事業の決算と必要書類の整理をするのですが、某社の会計ソフトを起動したところ自動更新の不具合でそのまま動かなくなりました。アクセスの自作会計ソフトをメインで使っていたので穏やかな年越しをすることができましたが、過信禁物ですね

(下の画像はアクセスではありません。Googleスプレッドで作った仕訳帳です)。

Googleスプレッドの仕訳帳。ギリギリ使えそうです。
ピボットテーブルが使えるので仕訳帳から試算表
決算整理は手入力ですが、BS、PLの小計が0になるようバランスするだけです


90年代はこの手の不具合はしょっちゅうでしたが2020年代になってもまだこんなことがあるとは!市販ソフトやクラウドはブラックボックスなのでシステム不具合時はバックアップも意味がありません。来年以降は電子帳簿ごとクラッシュするのでしょうか。

システム設計で一番重要な考え方は simple is best です。中でもデータベース設計がカギになります。重要なデータを格納するテーブルをコアテーブルと呼び、教科書通りの単純な構造とします。会計であればコアテーブルは1つしかありません、仕訳帳テーブルです。私のような個人事業者でも日本を代表するような大企業でも違いはありません。

重要な仕訳帳はEXCELに簡単にコピー出来るように設計します。何かトラブルがあっても仕訳帳を開くことはできます。そもそも記帳の手前で、EXCELのシートを費目別に分けて整理していると思います。自作の会計ソフトは費目別シートからの転記を便利にするために作ったものでした。

今回のケースはアプリケーション障害とデータ喪失にあたります。クラウドではないのでデータ流出の心配はありません。大ごとではありますが、別のアプリケーションを並列運用していたので実害はありません。社会インフラ系では、一世代前のシステムを待機系として維持する方式が以前はありましたが、最近は聞きません。現用系と待機系で異なるシステムを持つというのは、企業・商用システムの障害対策、可用性対策として見直されてもいいかもしれません。

Googleスプレッドの仕訳帳は、アクセスの会計ソフトをさらにシンプルに出来るのでは?と思いついて作ったものです。(総)勘定元帳兼用になっていてフィルターで勘定を絞ると相対勘定と合わせて確認することができます。決算整理は手入力ですがバランスさせるだけなので大した手間でもないと思います。アクセスは自動計算にしていますが、そのロジックを抜くとGoogleスプレッドで試算表まで行けてしまいます。Googleスプレッドで仕訳記帳と決算が出来るのは個人事業者にとっては大きいです。それを実感したくてEXCELで作ったものをGoogleスプレッドにUPしました。EXCELなのでソフトの使い方を新たに覚える必要もありません。これも大きいです。

結局 simple is best ということでしょうか。資産台帳、減価償却、在庫評価、原価計算などありませんが、私の仕事ではすべて0行なので。


2020年6月1日月曜日

マルチホーミング

マルチホーミング、わかります?ITの世界でマルチホーミングといえば物理的なネットワークの冗長化です。最近とんと聞かなくなりましたが、可用性確保で案外落とし穴かもしれません。クラウド流行りでエンジニアも希少化しているのではないでしょうか。インフラ担当としてアサインされたら焦りますよね。。


クラウドへのアクセスはアプリケーションプロバイダーの責任範囲から外れるのまずネットワークの冗長化要件が来ることはないのですが、以前は自前でマシンを設置してアクセス回線を手配していたので、冗長化も仕事の範囲でした。

最初に確認することは、NTT以外の幹線が建屋の近くの(道路の下)に来ているかで、来ていれば建屋への引き込みを依頼します。大技で有線回線と無線回線を併用するなんてのもありました。冗長化の趣旨からするとできるだけ異なる特性のものを組み合わせたほうが良いので悪くないアイデアです。

さて難しいのは、なじみの薄いL1,L2レイヤーを意識しないといけない点ですが、現在はフルIPなのでまだましですね。それでもルーターを用意してBGPの設定となると、なかなか手ごわいですね。できればパスしたいです。できるのでしょうか?
ことと場合によると出来ます。負荷分散としても割りと悪くない方式だと思います。概略を紹介します。

フロントウェッブは一般的なクラウドサービスに配置し、アプリケーションサービスを別のサービスサイトから提供することとします。マルチホーミングの対象はサービスサイトのみです。
ネームサーバーに www.***.com (フロント), svc1.***.com (サービス1), svc2.***.com (サービス2)の3ホストを登録します。フロントはサービス1、サービス2をタイムアウト付きでコールする javascript を組み込んだページを返します。
もうお分かりですね。サービス1が障害されていれば、タイムアウトしてサービス2にアクセスするという簡単なものです。サービス1のホストが回線A経由で、サービス2のホストが回線B経由でアクセスされます。2つのホストが同一DC内であれば疑似マルチホームで、別々のDCであればDC可用性確保になります。
* サービス1、サービス2のIPアドレスがクラスター共有されていれば元々の定義のマルチホーミングらしくなりますが、やるかどうかはユーザーメリット次第ですね。

何も難しいことはありませんし安上がりですぐに適用できますね。というか、DC可用性確保は基本しておいた方がいいです。有名なクラウドサービスもダウン前提ですから(フロントも複数のホストに配置し、ネームサーバーに登録ですよ)。
タイトルと書きだしを否定するようですが、ルーターでマルチホーミングなんて割りが合いません。ajax のおかげで手軽にサービスレベルを上げることができます。
システム設計は、ユースケース、アーキテクチュア、インフラトータルで見ましょう。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します)