Cloud Composer 向けの DAG ファイルの Syntax チェックをローカルで実行する - Qiita
いちいち gcloud composer environments storage dags import して web ui から確認していると日が暮れるので、手元で syntax チェックぐらいはしてから動作確認できるようにしてみた。 Docker イメージのビルド Airflow の docker イメージは https://github.com/puckel/docker-airflow にあった。 Composer 向けに google クライアントなどをいれる必要があったのでカスタム用の Dockerfile を自分で用意した。 # ref. https://github.com/puckel/docker-airflow FROM puckel/docker-airflow:latest USER root # Install additional packages requ
知らない技術は怖い - Mitsuyuki.Shiiba
AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？
Patterns of Service-oriented Architecture: Idempotency Key | Stitch Fix Technology – Multithreaded
In this installment of our “Patterns of Service-oriented Architecture” series, we’re going to talk about a complex concept called idempotency, and a technique you can apply to your service design to ensure that requested work is only performed once. Intent Prevent duplicate requests by allowing the Consumer of a Service to send a value that represents the uniqueness of a request, so that no reques
TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた - Qiita
はじめに UL Systems Advent Calendar 2018の10日目です。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース(DBなど)処理のみ行うローカルトランザクションと、1つのトランザクション内で複数のリソース処理を行うグロー
補正トランザクション | Microsoft Docs
一連のステップで構成される最終的に整合性がある操作を使用するときは、補正トランザクション パターンが役立ちます。 具体的には、1 つ以上のステップが失敗した場合、補正トランザクション パターンを使用して、ステップで実行された作業を元に戻すことができます。 通常、最終的整合性モデルに従う操作は、複雑なビジネス プロセスとワークフローを実装するクラウド ホスト型アプリケーションで見受けられます。 コンテキストと問題 クラウドで実行されるアプリケーションでは、データが頻繁に変更されます。 このデータは、異なる地理的場所にあるさまざまなデータ ソースに散在している場合があります。 分散環境で競合を回避しパフォーマンスを向上させるために、アプリケーションは、常にトランザクションの整合性を維持しようと努力すべきではありません。 代わりに、アプリケーションで最終的整合性を実装します。 最終的整合性モデル
SQL Server における分散トランザクション 1
神谷 雅紀 Escalation Engineer 分散トランザクション 分散トランザクションとは、複数のリソースマネージャーで実行されるトランザクションを、ひとつのトランザクションとして実行するトランザクションです。 リソースマネージャー リソースマネージャー (RM) とは、トランザクションによって更新されるデータを管理しているコンポーネントです。通常は、SQL Server や Oracle などのデータベース管理システムです。 トランザクションマネージャー トランザクションマネージャー (TM) とは、トランザクションを管理し、各リソースマネージャーに対してトランザクションに関する指示を出すソフトウェアコンポーネントです。SQL Server は、トランザクションマネージャーとして、Microsoft Distributed Transaction Coordinator (分散ト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
