メンテナンス画面の表示方法いろいろ | 外道父の匠
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
とある現場のシステムアーキテクチャ
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
Post by @instagram-engineering
What Powers Instagram: Hundreds of Instances, Dozens of Technologies One of the questions we always get asked at meet-ups and conversations with other engineers is, “what’s your stack?” We thought it would be fun to give a sense of all the systems that power Instagram, at a high-level; you can look forward to more in-depth descriptions of some of these systems in the future. This is how our system
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
先行開発！Javaでクリーンアーキテクチャ / Clean architecture with java