●発表のアーカイブ動画はこちら：https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座：https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「…
KubernetesのノードとしてWebAssemblyランタイムを用いる「Krustlet」、マイクロソフトが公開 Dockerコンテナによって実現された軽量で高速に起動するアプリケーション実行環境は、多数のコンテナから構成される分散アプリケーションの普及を大きく後押ししました。 分散アプリケーションの普及は、さらに軽量かつセキュアなDockerコンテナ実現へのニーズへとつながり、GoogleのgVisorやAmazon Web ServicesのFirecrackerといったセキュアなコンテナランタイムの実装や、同じくAWSによるコンテナに最適化したLinuxベースの軽量OSである「Bottlerocket」などを生み出すことになりました。 しかしいくらLinuxを軽量化したところで、OSであるLinuxの軽量化や機能の簡素化には限界があり、それはコンテナランタイムに対しても同様です。
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Mercari Advent Calendar 2018 の14日目はメルペイ DataPlatform チームの @syu_cream がお送りします。 本記事では表題の通り、メルカリとメルペイにおける、マイクロサービスのログ収集に関する課題と取り組みについて記載します。 メルカリとメルペイでは、現在クライアントアプリやサーバサイドのログを効率的に収集してサービスの他機能で活用するための基盤の開発を共同で行っています。 メルカリ・メルペイ間では、一部提供するサービスの差異やデータ管理のポリシーの都合によりインフラ構成が異なる部分はありますが、少なくとも思想や設計、実装は共有しています。 これの具体的な内容については、今回の Advent Calendar の 3 日目の記事に掲載しています。 本記事では、サービスを提供するサーバサイドアプリケーションから、この構成図における “A Ser
10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか
監視可能性は、マイクロサービスの初期段階から重要な原則でした。これは分散システム一般に当てはまるものですが、今日では(特にKubernetesにおいては)その大部分がプラットフォームレベルで最初から用意されています(プロセスのヘルスチェック、CPUおよびメモリ消費など)。アプリケーションに必要な最低限の要件は、JSON形式でコンソールにログを出力することです。それをもとにプラットフォームが、リソース消費量の把握、要求の追跡、あらゆる種類のメトリクスやエラー率の収集などを、サービスレベルでの開発をさほど必要とせずに実現してくれます。 クラウドネイティブなプラットフォームでは、監視可能性だけでは不十分です。それよりも基本的な前提条件が、ヘルスチェックの実装、シグナルへの対応、リソース使用量の定義などによって、マイクロサービスを自動化可能(automatable)にすることです。そうすることで、
Webアプリケーションを構築する上でレスポンスを向上させるための技術のひとつとしてキャッシングというものがあります。キャッシングされる仕組みは アプリケーションサーバ プロキシサーバ ブラウザ で実装されています。 W3Cではこれとは別にApplication Cacheという規格を定義しています。Single-page Applicationとの相性は良いとされていますがアーキテクチャの観点から何がどうなっているのかを今回は簡単に概要を述べたいと思います。 Application Cacheとは 静的なリソースに対してブラウザにキャッシングする仕組みがApplication Cacheです。AppCacheとも言うことがあります。実装は簡単で次のようHTMLへの定義およびmanifestファイルの記述でAoolication Cacheの実装が可能です。メリットはオフラインの状態でもur
Visual Studio 2017で作成したWindows Formアプリケーションのインストーラ作成方法を備忘録としてまとめてみた。 最新版はこちら。→Visual Studio 2022でインストーラ作成 過去にも自作ソフトを配布する際、何度かインストーラを作成して配布していたこもあったけど、ここ最近は、インストーラを作成せず、exeなどをzipで固めて配布していた。 その方が楽だし、利用者も抵抗感が少ないと思ったから。 でも、たまに実行権限の問題や、スタートアップ登録方法など問い合わせを受けることもある。 場合によっては、インストーラ付きでの配布を求められるシーンもある。 そんな訳で、また忘れてしまうであろうインストーラ作成方法をメモっておくことに。 昔はVisual Studioでセットアッププロジェクト(msi形式のインストーラ)を簡単に作成できたけど、 Visual Stud
κeenです。先日、Kubernetesの開発者が書いたKubernetes: Container Design Patternsというのを教えてもらって、面白かったのでそれを紹介します。 ただ漫然とコンテナを使っているだけでは気付かない使い方があったのでコンテナに興味のある方は是非一読下さい。 序論 オブジェクト指向が出てすぐにオブジェクト指向デザインパターンが産まれたように、分散システムにもデザインパターンが必要となってきました。 分散システムのデザインパターンの萌芽はHadoop/MapReduceに見ることが出来ますが、Javaに限られていました。 ところがここ数年の(Linuxの)コンテナ技術の躍進により欠けていたピースが埋まりました。分散システムパターンへのデプロイの抽象化です。 依存モジュールも一緒にデプロイ出来ますし、デプロイの状態も成功/失敗の二値になります。 それだけで
Kubernetes 疲れに Azure Container Apps はいかがでしょうか？（江東区合同ライトニングトーク 発表資料）
以下の文章は、Martin Fowler による Developing Patterns of Enterprise Software の日本語訳である。 以下は、個人的な調査で集めたエンタープライズ ソフトウェア開発に関するパターンのカタログである。 最終更新日: 2005/2/19 近年、小粒だが有用なエンタープライズ システム開発パターンが記述されてきている。 このページでは、特筆すべきパターンや、パターンの相互作用などについて述べていく。 各パターンに関するより詳しい情報については、 PatternShareを参照するとよいだろう。 ここはマイクロソフト パターン グループにより運営されており、 独自にパターン カタログの体系付けを行っている。 パターン作者を結びつける公式的な組織は存在していない。 しかし、私たちは非公式な関係で結びついている——お互いの作品をレビューしあっている
公開日: 2016年7月 Visual Studio 2017 RC の最新のドキュメントの詳細については、Visual Studio 2017 RC ドキュメントをご参照ください。 Visual C++ でビルドしたデバッグ バージョンのアプリケーションをテストする際は、そのアプリケーションが依存している Visual C++ ライブラリ DLL のデバッグ バージョンをテスト用のコンピューターに配置する必要があります。 配置する必要のある DLL は、「Visual C++ アプリケーションの依存関係の理解」に記載されている手順に従って確認できます。 Visual C++ ライブラリ DLL のデバッグ バージョンには、通常、"d" で終わる名前が付いています。たとえば、msvcr100.dll のデバッグ バージョンには、msvcr100d.dll という名前が付けられています。 メ
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
システム管理者として障害対応していると、アプリケーションやWindowsシステムが、エラー・ダイアログやログ・ファイルなどに出力したエラー番号から、原因を調査しなければならない場面に出くわす。通常はエラー番号だけでなく、適切なエラー・メッセージなども表示されるようになっているのだが、めったに発生しないようなエラーでは、単にエラー番号しか表示されないことがあるからだ。 このエラー番号でヘルプやマイクロソフトのサポート技術情報、各種インターネット・サイトなどを検索し、目的の情報が見つかればよいが、現実はそううまくいかないケースが多い。せめてエラー番号だけでなく、どのコンポーネントがエラーの原因になっているのかを類推できれば、検索に使うキーワードなどを工夫して、情報収集の作業を効率化できるはずだ。 このような目的に使える“err.exe”というコマンドライン・ツールがマイクロソフトから無償提供さ
64bit Windowsを前提とした32bitアプリケーション延命法 ～ LAAオプションで32bitアプリケーションのメモリ不足問題を解消 こんにちは。ウェブテクノロジの清水です。 Windowsアプリケーション開発者向けに、ちょっとしたTipsを紹介します。今回はVisual Studioの「LAAオプション」(LARGEADDRESSAWAREオプション、4GBオプション)という機能です。かなり便利な機能なのですが、知らない人も多いようです。 64bit化したくてもできない事情 オンメモリでデータを処理するタイプの32bitのWindowsアプリケーションでは、メモリ不足が結構深刻な問題となることがあります。 アプリケーションを64bit化すれば解決すると分かっていても、動作対象OSを64bit版Windowsのみに限定するのはユーザにとっても営業面から見ても抵抗がありそうです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
