タグ

ブックマーク / dev.classmethod.jp (4)

  • AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO

    こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと

    AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
    take4mats
    take4mats 2020/07/28
    これは発注側に、受注側は well-architected framework と一緒に?
  • 【書評】ゼロトラストネットワーク | DevelopersIO

    オペレーション部 江口です。 以前から気になっていた「ゼロトラストネットワーク」の翻訳版がオライリーから発売されました。 https://www.oreilly.co.jp/books/9784873118888/ 早速読んでみたのでレビューしてみたいと思います。 書籍の概要 最近新しいセキュリティの考え方として注目されている「ゼロトラストネットワーク」について取りあげた書籍です。 ゼロトラストネットワークの概念、どのように構成するか、認証をどうするべきかなどを解説し、またGoogleやPagerDutyでの実際のシステムの事例などを紹介しています。 目次 1章 ゼロトラストの基礎 2章 信頼と信用の管理 3章 ネットワークエージェント 4章 認可の判断 5章 デバイスの信頼と信用 6章 ユーザーの信頼と信用 7章 アプリケーションの信頼と信用 8章 トラフィックの信頼と信用 9章 ゼロト

    【書評】ゼロトラストネットワーク | DevelopersIO
    take4mats
    take4mats 2019/10/29
    気になる概念
  • 【11/1(金)東京】国内最大規模の技術フェス!Developers.IO 2019 東京開催!AWS、機械学習、サーバーレス、SaaSからマネジメントまで60を越えるセッション数! | DevelopersIO

    全60セッション以上!クラスメソッドの技術、すべて見せます。 クラスメソッドのトップエンジニア総出演 今年で5回目の開催を迎えるクラスメソッド主催のカンファレンスイベント Developers.IO 2019。今回ご用意したセッションの数は60以上。AWSはもちろん、SaaS、AI、DevOps、機械学習、認証、セキュリティLINEデータ分析、DeepRacerなどなど、最新のユーザー体験をもたらすテクノロジーからそれをささえる土台まで、ブログのDevelopers.IOにさらに盛ってお送りいたします。 さらに、レジレス技術やウォークスルー決済などで、Developers.IO CAFE技術セッションでは、クラスメソッド代表の横田聡らが登壇します。 豪華ゲストスピーカーも登場 今年のDevelopers.IOはゲストも多数登場!パラレルマーケターとして多岐にわたる活動を行っている小島英

    【11/1(金)東京】国内最大規模の技術フェス!Developers.IO 2019 東京開催!AWS、機械学習、サーバーレス、SaaSからマネジメントまで60を越えるセッション数! | DevelopersIO
    take4mats
    take4mats 2019/09/25
    面白そう
  • 複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO

    中山(順)です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を受けたというケースもあったようです。(以下、その一例です) 8月23日のAWSの大規模障害でMultiAZでも突然ALB(ELB)が特定条件で500エラーを返しはじめたという話 これは、

    複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO
    take4mats
    take4mats 2019/08/26
    ALBって少なくとも2つのAZを維持する必要がある。今回の事象を回避するには3つのAZを平常時用意していれば問題のAZだけ除外することが可能だった、と。ちなみにAZをアカウント関係なく識別できるIDも知れてよかった。
  • 1