タグ

jinjin252525のブックマーク (3,819)

  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
    jinjin252525
    jinjin252525 2021/04/08
    要件定義
  • [Spring Boot Actuator] 独自のヘルスチェック処理をマニュアル登録する方法 - Qiita

    Spring Boot Actuatorには、インスタンス自体やインスタンス内で依存している外部リソース(ディスク、DB、メッセージングサービス、キャッシュサービスなど)の稼動状態(ヘルスチェック結果)を提供するエンドポイント(/actuator/health, /actuator/health/{name})があり、独自のヘルスチェック状態を提供することもできます。 独自のヘルスチェック処理を自動登録する方法 Spring Bootのリファレンスにサンプルコード付きで紹介されていますが、HealthIndicatorインタフェースを実装したクラスをDIコンテナに登録すると、Spring Boot Actuatorが自動で検出してくれます。 @Component // コンポーネントスキャンでDIコンテナに登録 public class MyHealthIndicator implemen

    [Spring Boot Actuator] 独自のヘルスチェック処理をマニュアル登録する方法 - Qiita
    jinjin252525
    jinjin252525 2021/04/07
    Spring
  • 100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫

    100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫 PayPay 100億円キャンペーンのシステム構築 #2/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス (AWS) に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト部の山啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。後半パートとなる今回は、Shilei Lo

    100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫
  • mysqldump と mysqlpump どちらが速くバックアップできるか比較してみた

    こんにちは。エンジニアの阿久津です。 今回はMySQLmysqldumpmysqlpump という2つのコマンドでバックアップを実施しどちらが速く処理するのか比較してみましたので、それを記事にしたいと思います。 mysqldumpとは 従来のMySQLデータベースのバックアップ/リストアに用いられるコマンドです。 mysqlpumpとは MySQL5.7から追加された新機能で、 mysqldump の次世代となるコマンドです。 機能紹介 1. 並列処理(並列ダンプ) 複数のデータベース・テーブルを並列処理でバックアップすることができます。 MySQLサーバからデータを収集するために複数のスレッドを作成し、そのスレッドがそれぞれMySQLサーバへ接続してデータをまとめるためにキューに取得したデータを挿入する仕組みになっています。 オプションを何も利用せずにデフォルトで mysqlp

    mysqldump と mysqlpump どちらが速くバックアップできるか比較してみた
  • AWS におけるマルチアカウント管理の手法とベストプラクティス

    © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス部 プラクティスマネージャー 高田智己 2017年6月2日 AWSにおけるマルチアカウント管理の 手法とベストプラクティス セッションのスピーカー紹介 名前 高田 智己(Tomomi Takada) 所属 アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス部 プラクティス マネージャー プロフェッショナルサービスに おいて、エンタープライズのお 客様の主にセキュリティに関す る課題解決に従事 セッションの内容 • セッションはAWSで複数のアカウントを利用する場合 のメリット・デメリットを紹介し、お客様のマルチアカ ウント方針を考える際の手助

  • 進捗管理の精度を上げるためにTPMが行ったたった一つのこと - スタディサプリ Product Team Blog

    こんにちは。 今回は前回のバーンアップチャートの利用に引き続き、進捗管理の精度を上げるためにTPM(Technical Product Manager)の私が行ったことを書こうと思います。 具体的に行ったことはたった一つで、 「自分自身でタスクの雑見積もりをしてみる」 です。 どんな人に読んでほしいか ProductのManagementをしている中で、一つ一つのタスクがどれぐらい大変なのかがわからない人 エンジニアにはなるべく開発に時間を使ってほしいと思っている人 見積もりってどうやってやればいいか全くイメージの湧いていない人 TL;DR タスクを見積もりができる粒度に切り分けましょう 自分がエンジニアになったつもりでどうやって実装するのかを考えてみましょう 最低でも1日で終わるのか、2日以上かかるのかというレベルでもいいので見積もりをすることで完了予定日のズレが軽減されます 副次的に詰

    進捗管理の精度を上げるためにTPMが行ったたった一つのこと - スタディサプリ Product Team Blog
  • アカツキでAWS ECS Capacity Providerと格闘して - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

    こんにちは! この度サーバサイドエンジニアとしてインターンシップで勤務させていただきました、髙津と申します。 記事では、インターンシップ期間 (2020年7月6日〜7月31日) 中に取り組んだこと、感じたことなどを書いていきます。似たような技術課題に直面している方々、これからインターンシップを受けようと考えている方などの手助けになれば幸いです。 具体的には インターンシップで取り組んだこと 知見 Capacity Providerの具体的な設定項目 Auto Scalingの仕組みのおさらいと設定項目一覧 検証 懸念事項 1. 動作の上で最適な設定は何か? 1.1. SSPタイプはどちらが良いのか? 1.2. Scalingトリガーとして適切なメトリクスは何か? 2. Scalingは十分に速いか? 3. 安全にScale Inできるか? まとめ インターンシップを通じて感じたこと 取り

    アカツキでAWS ECS Capacity Providerと格闘して - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)
    jinjin252525
    jinjin252525 2021/02/03
    ecs autoscalle
  • Capacity Providers をもっと身近に / Introduction of Capacity Providers

    jinjin252525
    jinjin252525 2021/02/03
    ecs autoscalle
  • The Twelve-Factor Appで考えるAWSのサービス開発

    1. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. The Twelve-Factor App で考える AWS のサービス開発 31 October 2018 Amazon Web Services Japan Solutions Architect Fumihiko Hata ,Yuki Chiba 2. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. スピーカー紹介 千葉 悠貴 アマゾン ウェブ サービス ジャパン株式会社 シニアソリューションアーキテクト 畑 史彦 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 4. © 2018, Amazon Web

    The Twelve-Factor Appで考えるAWSのサービス開発
  • 担当マイクロサービスのSLI/SLOを見直そうと思ったんだ - エムスリーテックブログ

    エムスリーエンジニアリンググループの関根(@sekikatsu36)です。 この記事はエムスリーSREがお届けするブログリレーの14日目です。 今回、私のチームが担当しているサービスのSLI/SLOを見直すこととなり、あらためて「マイクロサービスのSLI/SLOとは」を自分なりに考える機会ができたため、その話を紹介したいと思います。 まだ実行中で結論は出ておらず、内部でも議論の余地があるものですが、何かご参考になる点があれば幸いです。 事の発端 ビジネスサイドとの対話 方針転換 終わりに We are Hiring! エムスリーでは数百のマイクロサービスを開発・運用していますが、今回は私の所属チームで担当している「医療ニュースの管理サービス」を取り上げます。 このサービスは、ニュース記事を表示するWebページ、ニュース記事を登録・取得するAPI、リコメンドやメルマガのための記事情報を分析・

    担当マイクロサービスのSLI/SLOを見直そうと思ったんだ - エムスリーテックブログ
    jinjin252525
    jinjin252525 2021/02/01
    sre
  • 私がインフラエンジニアとして働くにあたって大切にしている基本的な考え方

    jinjin252525
    jinjin252525 2021/01/29
    インフラエンジニア
  • AWS Network Firewall が激アツ

    November 18, 2020 久しぶりにテンション上がるニュースが出たので野次馬的にまとめていきます。 AWS Network Firewallについてです。 機能まとめ 保護対象サブネット→NAT→firewall専用サブネット→インターネットゲートウェイというトラフィックを要求する fw専用サブネットを切るが、この専用サブネットはスキャン対象外であるため 内部はgwlbを経由してigwから外へ出るとある、ので、終端IPはNAT名義かも 実パケットを問答無用でフルで受け取るアーキテクチャであり、ステートレスルール以外の処理はパケットをまとめてL7レイヤ的なチェックが確定なので、Firewallが通信遅延につながる可能性は高い。そもそもホップも増えるし。 firewallは建てるだけで月3万、トラフィックは0.06$/1gbと割と安い。内部的に依存しているgwlbの料金は不明…タダな

    jinjin252525
    jinjin252525 2021/01/29
    firewall
  • Redis Keyspace Notificationsで発火されるイベントを見てみる - daisuzz.log

    Redis Keyspace Notificationsとは Redisには、キーに影響を与えるコマンドが実行されたタイミングや、キーが期限切れになったタイミングなどにRedisのPub/Subチャネルを介してクライアントにイベントを通知するRedis Keyspace Notificationsという機能があります。 CPUにある程度負荷がかかることを考慮してRedisのデフォルトでは無効になっていますが、Spring Sessionで利用する際には設定を有効にしておかないと、期限切れのセッションがRedisに残り続けパフォーマンスに影響を与えることになります。 ※ Spring SessionではRedisサーバ側でRedis Keyspace Notificationsが無効になっていても、自動的にCONFIGコマンドを実行して有効にしてくれますが、クラウドサービスが提供しているマネ

    Redis Keyspace Notificationsで発火されるイベントを見てみる - daisuzz.log
    jinjin252525
    jinjin252525 2021/01/29
    redis
  • チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ

    こんにちは、エムスリー エンジニアリンググループ / 製薬企業向けプラットフォームチームの鳥山 (@to_lz1)です。 この記事はエムスリーSREがお届けするブログリレーの8日目です。 このブログリレーで複数回言及されているように、エムスリーでは昨年から大々的に「チームSRE」という制度を導入しています。従来からのSREすなわち「コアSRE」が受け持っていた業務や権限を、各プロダクトチーム内のSREすなわち「チームSRE」に委譲している真っ最中です。 私の所属する製薬企業向けプラットフォームチーム(Unit1と呼ばれています)のチームSREの導入タイムラインは、以下のような感じです。 2020年4月に最初のチームSREが入社 2020年7月ごろに私を含む6名がチームSREとして追加 複数サービスのクラウド移行を実施しつつ今に至る したがって、少なくとも私のチームではこの「チームSRE」と

    チームSRE立ち上げ期にやってみて良かったこと - エムスリーテックブログ
    jinjin252525
    jinjin252525 2021/01/22
    sre
  • SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ

    エムスリーエンジニアリンググループSREチームの山です。 私はエムスリーに入社してまだ1年少しなのですが、前職でも似たような職務を担当していました。 その中で、実は「インフラのあり方」には二大潮流が存在し、その中で皆が苦しみもがいているのではないだろうか?と感じました。前職や現職で感じたアレコレをエッセーのように軽い読み物にしますので、SREブログリレー二日目のネタとして書かせてください なお、文字だけでは書きたいことが足りぬため、私が直々に画伯として挿絵も描いてしまいます。 ちなみに「麻雀に例えたら」と書きましたが、実は私は麻雀のルールをほとんどしりません。某有名麻雀劇画の作者はルールを知らないのに勢いで麻雀を描いたようですし、私もそれでいきたいと思います。 ロン!クラウド無双!! 二種の潮流 哭きのSRE メンチン型SRE どちらが正しいのか? SREとしての立場と技術選定 「シクヨ

    SREを麻雀に例えたら(哭き派とメンチン派の争い) - エムスリーテックブログ
  • SREの民主化とクラウド移行 - エムスリーテックブログ

    あけましておめでとうございます。今日から02/05までの平日にエムスリーのSREでブログリレーを開催します。その初日の投稿を担当させていただくエムスリーエンジニアリンググループの岩佐です。グループリーダーという立場でSREチーム、基盤チーム、セキュリティチーム、Unit4(m3.com/サイトプロモ)を担当しています。 私からはエムスリーでSREを拡大しようと推進している経緯/流れについて一筆認めさせていただこうかと思います。 要約、早速だけど 経緯、メンバーに敬意を、チームに契機を 方針、状況に合わせて更新 計画、そして軽快に改革 まとめ、ちょっとまともに 要約、早速だけど SREを短期的に大量に採用するのは不可能、じゃないかのう? オンプレミス環境で拡大していくサービス群をSREチームのみが運用していくのは難しい。こんなん困難では?はー、どうしよう 権限の移譲、DevOpsの推進をする

    SREの民主化とクラウド移行 - エムスリーテックブログ
  • エンベロープ From と Return-Path と Errors-To と - Customers Mail Cloud ブログ

    送信したメールがエラーになると、それを知らせるメールが戻ってきます。 今回は、そのメールがどこに戻ってくるのかについてお話しします。 はい、あなた。『そんなの送信した人の所に決まってるよ。』と思いましたね。 その通り。送信した人の所です。 でも、その送信した人って誰? 普通の郵便、紙のヤツね、あれを思い出すと宛先の他に差出人の住所・氏名も書きますよね。 それで、宛先が間違っているとその差出人の所に「宛先不明」みたいなゴム印を押されて戻ってきます。 メールも同様です。 メールを送信するときには宛先のメールアドレスの他に差出人のメールアドレスも指定します。 この差出人のメールアドレスにエラーメールが戻ってきます。 このメールを送信するときに指定するメールアドレスを宛先はエンベロープ To、差出人はエンベロープ From と言います。 エンベロープ From は、メールを送信するプロトコル SM

    エンベロープ From と Return-Path と Errors-To と - Customers Mail Cloud ブログ
  • キャリア | スタディサプリ BRAND SITE

    Bringing the Best Education to Every Corner of the World 国境や貧富の差を超えて誰もがアクセスできる知のプラットフォームを作り上げたい。世界で誰もが学びたいものを自由に効率的に好きなだけ学べるようにしたい。この”知恵の流通革命”を実現するためにスタディサプリは始まりました。 教育によって世界を変える。 共にチャレンジしてくれる仲間をスタディサプリでは募集しています。

    キャリア | スタディサプリ BRAND SITE
  • Production Readiness Check のはじめかた - スタディサプリ Product Team Blog

    こんにちは。SREの近藤(@chaspy)です。 新しいサービス、あるいは Microservices を 番環境へリリースする際、私たちは何を注意すべきでしょうか。 今回は、Production Readiness CheckList と導入方法について説明します。 Production-Readiness Checklist とは Service を番環境へリリースする前の、信頼性観点でのチェックリストです。このチェックリストを事前に行うことによって、番での Service 運用開始後の問題をなるべく引き起こさないようにする、あるいは起きたときに最善な手が打てることが期待できます。 Production-Ready Microservices (日語版:プロダクションレディマイクロサービス ――運用に強い番対応システムの実装と標準化 を読まれたひとも多いと思います。書の付録

    Production Readiness Check のはじめかた - スタディサプリ Product Team Blog
  • WikiLeaksがAWSのデータセンター所在地を暴露したので詳細を見る - Qiita

    WikiLeaksがAmazonのデータセンターの所在地を暴露 しましたね。民間企業の機密情報のリークは公益性のない行為のように感じたものの情報としては面白いので日を中心に詳細なデータを見ていこうと思います。 WikiLeaks - Map of Amazon's Data Centers 🌏AWSの リージョン/AZ とは 知ってるわいという方は読み飛ばしてください。クラウドではデータセンター、アベイラビリティゾーン、リージョンという言葉がでてきますが、各クラウドプロバイダによって言葉の使い方が少し異なります。AWS では以下のように定義されています。 データセンター(DC) 物理的なビル、またはビル群 AvaliabilityZone(AZ) 1つ以上 のデータセンターで構成したゾーン Region 2つ以上 のAZから成り立つグループ Transit Cernter AZとAZ外

    WikiLeaksがAWSのデータセンター所在地を暴露したので詳細を見る - Qiita