並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 850件

新着順 人気順

分散システムの検索結果121 - 160 件 / 850件

  • misskeyの急速な流行と分散型SNSの限界 | 右や左の旦那様

    はじめに 前回の記事から11日、misskeyを取り巻く環境が日々変化しているので、今回はmisskeyに焦点を当てたブログを書こうと思います。 misskeyとは、misskey.ioとは misskeyは分散型SNSの一種であり、日本製であることから日本人の間でtwitterからの移行先として注目されています。 misskey.ioは中でもmisskey開発者が運営するも所属しているインスタンスであり、misskey派閥の中でも最大規模のインスタンスとなっています。 「分散型SNS」や「インスタンス」について詳しくは前回の記事を参照いただければと思いますが、ざっくり言えばmisskeyというソフトウェアを作った本人が運営してるも所属している最大手のサーバーがmisskey.ioだよ、ということです。 [追記] 開発者本人は運営してないよ、という情報がありましたので訂正します。ごめんなさ

      misskeyの急速な流行と分散型SNSの限界 | 右や左の旦那様
    • Managed Kubernetesサービス開発者の自宅k8sクラスタ全容

      となっています。 構成図 クラスタを構成するものを図にすると以下のようになります。 この中の一部コンポーネントは次節以降で登場します。 Kubernetes基盤 クラスタの基盤部分についてどのような構成になっているのか説明します。 kubeadm クラスタの構築自体については kubeadm を利用しています。 kubeadm を利用したクラスタの構築方法については公式のドキュメントが参考になります。 Static Pod と systemd kubeadm でデプロイすると kube-apiserver 等は Static Pod で、kubelet は systemd 以下で動作するようになります。 kube-apiserver は意外にメモリを食ってしまうのでそのまま動作させているとメモリ不足になることがあります。(ありました) なので kube-apiserver と etcd の

        Managed Kubernetesサービス開発者の自宅k8sクラスタ全容
      • ゼロから学んだ形式手法 - DeNA Testing Blog

        2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek(@takasek)です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています(形式手法 カテゴリーの記事一覧)。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造(モデル)を与え、そのモデルを解決の機構に落

          ゼロから学んだ形式手法 - DeNA Testing Blog
        • gRPC Internal - gRPC の設計と内部実装から見えてくる世界 | Wantedly Engineer Blog

          こんにちは、Wantedly の Infrastructure Team で Engineer をしている南(@south37)です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もその一環となっています。 Wantedly における Go 導入にまつわる技術背景 | Wantedly Engineer Blog (本記事は Go Conference 2019 Autumn にて無料配布した冊子『WANTEDLY TE

            gRPC Internal - gRPC の設計と内部実装から見えてくる世界 | Wantedly Engineer Blog
          • [速報]AWS、自身でプロセッサを開発していく姿勢を明らかに。独自開発の第二世代ARMプロセッサ「Graviton 2」発表。AWS re:Invent 2019

            Amazon Web Services(AWS)は、米ラスベガスで年次イベント「AWS re:Invent 2019」を開催中です。 開催3日目に行われたキーノートスピーチには、同社CEO Andy Jassy氏が登場。 x86プロセッサのサーバと比較して、40%も価格性能比が高いとのこと。 チップデザイン会社の買収がターニングポイントだったとAndy Jassy CEO Jassy CEOは、2015年にAWSがイスラエルのチップデザイン会社であるAnnapurna Labsを買収したことが、同社にとってターニングポイントだったと振り返ります。 同社がAnnapurna Labsを買収した当初の目的は、Amazon EC2におけるサーバの仮想化機能をより高性能化するためにハードウェアへのオフロード用ASICを自社で開発するためだと説明されていました。 このASICは「Nitro Syst

              [速報]AWS、自身でプロセッサを開発していく姿勢を明らかに。独自開発の第二世代ARMプロセッサ「Graviton 2」発表。AWS re:Invent 2019
            • ウクライナ侵攻とインターネット – JPNIC Blog

              dom_gov_team 2022年3月11日 IPアドレス インターネットガバナンス ドメイン名 2022年2月下旬に始まったロシアによるウクライナ侵攻は、2週間以上が経った今も収まらず、事態が憂慮されます。日本はウクライナを支持しロシアを非難する立場から、支援や制裁を打ち出しており、多くの西側諸国でも同様です。そんな中インターネット基盤に関してどのような動きがあるか、本稿にまとめてみました。 ウクライナ副首相がICANNに対してロシアのccTLDの無効化などを依頼 ウクライナの第一副首相兼デジタルトランスフォーメーション大臣ミハイロ・フェドロフ氏からICANNに宛てられた2022年2月28日の書簡において、 ロシアのccTLD (.ru , .su , .РФ)の無効化 これらのccTLDに対するSSL証明書の無効化推進 ロシア連邦に設置された2つのルートDNSサーバの無効化 の3点が

              • QUICはTCPの代替ではない

                ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え

                • Goのerrorがスタックトレースを含まない理由 - methaneのブログ

                  Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案

                    Goのerrorがスタックトレースを含まない理由 - methaneのブログ
                  • 今なら間に合う分散型IDとEntra Verified ID

                    6/30のOffice365勉強会のEntra Verified ID特集の資料です。 分散型ID、Entra Verified IDの解説をしています。Read less

                      今なら間に合う分散型IDとEntra Verified ID
                    • 【2024年】ITエンジニア本大賞まとめ - Qiita

                      アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために! 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、

                        【2024年】ITエンジニア本大賞まとめ - Qiita
                      • サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発

                        2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo

                          サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
                        • ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ

                          builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMessaging - Choreography - EventDriven - EventSourcing - SagaPattern

                            ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
                          • [速報]「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019

                            [速報]「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019 Amazon.comが開発してきた世界最大級の電子商取引システムや、それを支えるインフラであるところのAmazon Web Servicesは、世界でも最も複雑で巨大な分散システムの1つです。 そしてAmazon.comやAWSにとってさえ「分散システムの構築は難しいものだった」と、Amazon.com CTO Werner Vogels氏。 そしたなかで、Amazonはどのように堅牢でスケーラブルな分散システムを作ったのか? エンジニア組織をスケールさせてきたのか? どのように運用しているのか? どうやってサービスを迅速に提供しているのか? AWSのブログに投稿された記事「Check

                              [速報]「The Amazon Builders' Library」発表。大規模分散システムの構築、運用などについて、Amazonが学んできたことをコンテンツとして公開。AWS re:Invent 2019
                            • 分散システムの課題

                              Amazon が 2 台目のサーバーを追加した時から、分散システムは Amazon で馴染み深いものになりました。私が 1999 年に Amazon に入社したとき、サーバーの数が非常に少なかったため、「fishy」や「online-01」などのわかりやすい名前を付けることができました。けれども、1999 年であっても、分散コンピューティングは容易ではありませんでした。また現時点で、分散システムの課題には、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑さが含まれます。システムが急速に大きくなり、分散するにつれて、理論的なエッジケースであったものが定期的に発生しました。 信頼できる長距離電話ネットワークやアマゾン ウェブ サービス (AWS) のサービスといった分散ユーティリティコンピュー

                                分散システムの課題
                              • 日本ブロックチェーン協会ユーゾー代表理事曰く「マイナンバーにブロックチェーンⓇを」「しかもASCII」

                                玉木雄一郎(国民民主党代表) @tamakiyuichiro #国民民主党 ( @DPFPnews )代表。さぬきうどんとギョーザ定食が好きな衆議院議員(香川2区)永田町のYouTuber「たまきチャンネル」youtube.com/@tamaki-channel インスタもやってます! ameblo.jp/tamakiyuichiro/ 玉木雄一郎(国民民主党代表) @tamakiyuichiro 世界3位の時価総額を誇る東証の終日取引停止はIT先進国とは言えない事態。日本の株式市場に対する世界からの信頼が損なわれかねず速やかな復旧を求めたい。他の取引所にも拡大しておりサーバー型ではなくシステムのブロックチェーン化など分散化を進める必要もあると思う。 news.yahoo.co.jp/pickup/6372518 2020-10-01 16:12:12

                                  日本ブロックチェーン協会ユーゾー代表理事曰く「マイナンバーにブロックチェーンⓇを」「しかもASCII」
                                • Nostr の面白さをエンジニア目線で解説してみる

                                  はじめに 今年は、SNS でありプロトコルでもある Nostr に出会いました。2023年2月の参加でしたがもう、どういった経緯で Nostr を見付けて参加したのかすら思い出せなくなってしまいました。ここ数年、X/Twitter が API という物を開発者に触らせなくなってしまいました。僕は X/Twitter が大きくなった理由の1つが、API をオープンにした事で数多くの bot やサービスがが登場した事だと思っていて、API が自由で無くなった X/Twitter をとても残念に感じています。次第に SNS に関連する何かを作るモチベーションはさっぱり無くなってしまっていました。 そんな中で見付けた Nostr はエンジニアのオアシスとでも言える SNS だと感じました。 Nostr の思想 X/Twitter は中央集権型の SNS であり、以下の様な問題を持っています。 障害

                                    Nostr の面白さをエンジニア目線で解説してみる
                                  • 実用 Go言語

                                    業務プログラミングの現場でも採用されるようになってきたGo言語。文法はシンプルで学びやすいという特徴を持っていますが、複雑な要件を実現するには、プログラミング言語が提供する構成要素(文法やライブラリ)をさまざまに組み合わせる必要があります。 本書は、そんなGoを使う上でのポイントを単なる文法詳解ではなく「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点から紹介します。 構造体やインタフェースの使い方からJSON、CSVファイル、Excel、固定長ファイルの扱い方、またログやテスト、環境構築など現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」をその背景と共に教えてくれる先輩のような書籍です。 まえがき 1章 「Goらしさ」に触れる 1.1 変数やパッケージ、メソッドなどに名前を付けるには 1.1.1 変数名 1.1.2 パッケージ名 1.1.3 

                                      実用 Go言語
                                    • Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで - Findy Engineer Lab

                                      自分が気づいてなかった資質を、探して、磨く 劣等感に消耗するより、目的志向で考える オープンソースコミュニティへの参画 ドメイン駆動設計とScalaが「点」となる ドメイン駆動設計との出会いと成果 遅延評価的学習法でScalaを習得 Scalaを使ってDDDを実践するスタイルを確立した 実験的に導入して結果が出れば業務での普及も進む 積み上げてきたScalaとDDDの開発スタイル Scalaコミュニティとともに 新しい挑戦で新しい「点」ができ、そして「線」につながる 「いずれどこかで点がつながって実を結ぶだろう」 過去も未来も思い切って手放し、今の自分に集中する こんにちは、Chatworkでテックリードをしている、かとじゅん(@j5ik2o)です。 今年(2020年)で48歳になりましたが、技術に前向きになったというか、本気を出したのは37歳ごろでした。遅いな……(笑)。まぁ、遅い早いが

                                        Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで - Findy Engineer Lab
                                      • iOSエンジニアとして入社した僕が AWS認定資格 11冠 になった話 | DevelopersIO

                                        試験を受けるきっかけ 僕が入社した当初、資格取得を奨励していたこともあり、半ば強制でソリューションアーキテクト – アソシエイトの試験を受験させられました。今考えれば 完全にパワハラ ですよね。 それから2年後、iOS開発者として色々な案件に従事してきましたが、いろいろな領域の開発に興味が出てきたこともあって、サーバーレスアーキテクチャを採用した開発案件に飛び込みました。ちょうどその頃、 サーバーレス開発部 の立ち上げが重なり、 AWS の勉強を本格的に始めました。 SAP [期限: 2017-11-30] DOP [期限: 2017-11-30] Chatwork のタスクにこの2つが 部長 から追加されていたことは今でも忘れられません。 今考えれば 完全にパワハラ ですよね。ただ、労働基準局に駆け込むよりも「よし、やってやろう」という気持ちの方が大きかったです。取得した ソリューション

                                          iOSエンジニアとして入社した僕が AWS認定資格 11冠 になった話 | DevelopersIO
                                        • “Tao of Node - Design, Architecture & Best Practices” 日本語翻訳

                                          私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し

                                            “Tao of Node - Design, Architecture & Best Practices” 日本語翻訳
                                          • 設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog

                                            この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 (結局「書くの?書かないの?どっちなんだい!」と感じた人は、ぜひ読み進めてください。) 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法

                                              設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog
                                            • Mercari Microservices Platformの進捗(2019年) | メルカリエンジニアリング

                                              Microservices Platform TeamでTech leadをしている@deeeeeeetです. 昨年のMTC2018ではMicroservices Platformチームの立ち上げから1年で僕らが取り組んできたことを紹介しました. speakerdeck.com 具体的にはStranglerパターンによるMonolithからMicroservicesへの段階的なリクエスト移行を行うためのAPI gatewayの開発や,Microservicesのインフラのセットアップを簡単にしサービス開発チームのSelf-service化を進めるためのStarter-kitの開発,GoでのMicroservicesの開発を高速で始めるためのTemplateプロジェクトの開発,Spinnakerの導入などについて紹介しました. これらはPlatformとして最低限の機能を整備したにすぎず,さ

                                                Mercari Microservices Platformの進捗(2019年) | メルカリエンジニアリング
                                              • 分散型IDに関する10の所感(2022年2月版)

                                                いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。(往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする) ※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・ また機会があればdidconでも開催してじっくりお話さ

                                                • ZOZOテクに入社してもうすぐ1年半になるので、リアルな話をしたい - inductor's blog

                                                  はじめに タイトルは釣りです(テンプレ) はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。 ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。 社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots) 自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です! 入社の経緯とか そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担

                                                    ZOZOテクに入社してもうすぐ1年半になるので、リアルな話をしたい - inductor's blog
                                                  • 正しいクラウドはある意味で遅い - Software Transactional Memo

                                                    TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは

                                                      正しいクラウドはある意味で遅い - Software Transactional Memo
                                                    • NewSQLのコンポーネント詳解 - Qiita

                                                      4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー

                                                        NewSQLのコンポーネント詳解 - Qiita
                                                      • モダンなシステムにSLI/SLOを設定するときのベストプラクティス

                                                        New RelicではどのようにSLI/SLOを定義し、SREを実践しているか。その経験から、SLI/SLOについて解説した記事 Best Practices for Setting SLOs and SLIs For Modern, Complex Systems の翻訳です。 -- New Relicのサイト信頼性VPであるMatthew Flamingも、この記事に貢献しています。この記事はサンフランシスコその他で行ったFutreStack18での講演「SLOs and SLIs In The Real World: A Deep Dive.」をもとに作られています。 New Relicでは、サービスレベル指標(Service Level Indicator: SLI)とサービスレベル目標(Service Level Objective: SLO)を定義したり設定したりことが、サイト

                                                          モダンなシステムにSLI/SLOを設定するときのベストプラクティス
                                                        • RDBの限界とNoSQLの登場 - Qiita

                                                          事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html NoSQLの登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャーディング

                                                            RDBの限界とNoSQLの登場 - Qiita
                                                          • クローラー運用を楽にするためのクラウドサービス比較 - ZOZO TECH BLOG

                                                            こんにちは!最近気になるニュースはスピノサウルスの尻尾の化石が発見されたこと1な、SRE部エンジニアの塩崎です。ZOZOテクノロジーズの前身となった会社の1つであるVASILYでは数多くのクローラーの開発・運用の担当をしてきました。 今回はその知見を生かして、クローラーを楽に運用するためのクラウドサービスを紹介します。 概要 データ解析を円滑に進めるためには、CSVやWeb APIなどの構造化されたデータが必要です。しかし全てのWebサイトにあるデータが構造化データを提供しているとは限りません。むしろ提供していないケースの方がはるかに多いです。そのため、Webクローラーを作成して構造化されていないWebページを解析し、構造化データを生成する必要があります。 しかし、Webクローラーの運用には数多くの「つらみ」があります。特に大量のWebページを1日1回などの頻度で定期的にクロールする際には

                                                              クローラー運用を楽にするためのクラウドサービス比較 - ZOZO TECH BLOG
                                                            • 今後は「データ指向アプリケーションデザイン」を考えよう(Red Hat Forum講演フォローアップ記事) - 赤帽エンジニアブログ

                                                              Red Hatの須江です。 本記事は赤帽エンジニア Advent Calendar 2019の10日目です。 子供を皮膚科に連れて行ったりなんだりで、気づいたら12/11になってますが、細かいことは気にせず進めます。 セッション資料と動画 redhat.lookbookhq.com redhat.lookbookhq.com 「データ指向アプリケーションデザイン」をメインテーマに選んだわけ デジタルトランスフォーメーション(DX)がバズワード化して久しいですが、自分は常に「DXは目的ではなく手段なので、DXしたあとにどうありたいかのビジョンを持ち、そこから逆算していまやることを考える」ことが重要だと考えています。 ビジョンを持つためには、まずDX後の世界がどうなっているのかをイメージできるようになる必要があります。 そこで、2019/6/20に開催された「DX&Open Hybrid Cl

                                                                今後は「データ指向アプリケーションデザイン」を考えよう(Red Hat Forum講演フォローアップ記事) - 赤帽エンジニアブログ
                                                              • サーバーレス時代のKubernetesワークロード:アーキテクチャ、プラットフォーム、トレンド

                                                                SOAは優れた原則に基づいており、その大半はまだ有効です。それは契約優先開発、疎結合、構成可能、ステートレスなサービスであり、自律的で再利用可能です。 ESBフレームワークは、プロトコル変換、テクノロジーコネクタ、ルーティングおよびオーケストレーションメカニズム、エラー処理、高可用性プリミティブなどの優れた機能セットを提供しました。 分散アーキテクチャの進歩 SOAとESBの主な問題は、アーキテクチャと組織の両方の観点からの集中化でした。SOAの重要な原則は、サービスとコンポーネントの再利用でした。これにより、再利用を可能にするが、緊密なアーキテクチャ上のサービスカップリングを引き起こす階層化サービスアーキテクチャが作成されました。組織的には、ESBは単一のチームによって所有されていました。それによって、ミドルウェアは、スケーラビリティの観点で、さらに重要なことに急速な進化の観点で技術的お

                                                                  サーバーレス時代のKubernetesワークロード:アーキテクチャ、プラットフォーム、トレンド
                                                                • スタンフォードのコンピュータサイエンスの授業の感想(後編)|Rui Ueyama

                                                                  2017年にも同じタイトルの記事を書いたのだけど、その後無事にスタンフォード大学院のコンピュータサイエンス学部を卒業することができたので、前回の記事以降に取った授業について、僕なりの感想をちょっとまとめたい。 CS255 暗号入門 (2018Q1)文字通り暗号についての授業。対称鍵暗号、公開鍵暗号、メッセージ認証、一方向ハッシュ関数などのトピックについて学ぶ。プログラミングではなく理論中心の授業。 宿題では、例えばこういう手順で暗号化される通信が安全であることを証明せよ、みたいな問題が出た。こういう問題は、もし安全ではないとしたらそれを利用して安全とされている暗号(AESとか)を破れてしまう、みたいな背理法で証明を行う。そういう巧妙な証明を考えるのは結構面白かった。あるいは逆に、このように暗号化された通信方式の穴を見つけよ、みたいな問題も出た。 AESやSHA256そのものがなぜ安全と思わ

                                                                    スタンフォードのコンピュータサイエンスの授業の感想(後編)|Rui Ueyama
                                                                  • 2022年にやったこと - k0kubun's blog

                                                                    2021年にやったこと 2020年にやったこと 2019年にやったこと 2018年にやったこと 2017年にやったこと 2016年にやったこと 2015年にやったこと 今年のハイライトは 大学院を卒業し、CS修士号を取った グリーンカードを取った Shopifyに転職し、仕事でRubyのJIT開発を始めた という感じの一年だった。 大学 5月にジョージア工科大学のCS修士を卒業した。 ほとんどの人は3~4年かけて卒業するプログラムを、理論上最速である1年9か月で卒業するRTAをやっていた。 かといって特に雑になるでもなく、GPA 3.90/4.00 だったので、GPA 3.36だった学部の時よりかなりマシな成績を取っている。 なんかその記事に書くとダサくなりそうなので書かなかったが、よく宿題の提出期限になる月曜の朝5時はほぼ毎週起きててギリギリに提出するくらいには大変だった。4:57~4:

                                                                      2022年にやったこと - k0kubun's blog
                                                                    • AWS Lambdaの高速なコンテナロードの仕組み | CyberAgent Developers Blog

                                                                      CTO統括室の黒崎(@kuro_m88)です。今回はAWS Lambdaの高速なコンテナロードの仕組みについて紹介します。 AWS Lambdaはサーバレスなマネージドサービスであり、難しいことを知らなくてもユーザ(私たち)は簡単にアプリケーションをホストでき、簡単にスケールします。 ユーザから見るとシンプルですが、その裏側では様々な仕組みがあったり最適化が行われたりしています。 マネージドサービスの裏側を必ずしも知る必要はありませんが、仕組みを知っておくとより使いこなせるはずですし、自信を持って技術選定ができるはずです。(そして何より裏側を知ることは楽しい!🤗) 本記事はUSENIX ATC 2023で発表された論文「On-demand Container Loading in AWS Lambda」の内容に基づいて、読んでいて面白かったポイントをまとめています。 On-demand

                                                                        AWS Lambdaの高速なコンテナロードの仕組み | CyberAgent Developers Blog
                                                                      • ただのソフトウェアエンジニアが検索エンジニアになるまで - エムスリーテックブログ

                                                                        こちらはエムスリー Advent Calendar 2022 Advent Calendar 2022の延長戦31日目の記事です。 エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。検索とGoが好きです。 検索エンジニアってどこで採用できるの? という話を至る所でよく聞きます。僕自身も、自ら検索エンジニアと名乗るエンジニアにほとんど出会ったことがありません。やはり、世の中の検索にまだ魅了されていないエンジニアを情報検索の世界に引き込むしかないので、今回は僕が情報検索にハマった経緯を紹介することで一人でも多くのエンジニアを情報検索の世界に引き込めればと思います。 情報検索との出会い 情報検索の探索 発展 まとめ 情報検索との出会い 僕が最初に情報検索に出会ったのは前職の白ヤギコーポレーションでした。そこではElasticse

                                                                          ただのソフトウェアエンジニアが検索エンジニアになるまで - エムスリーテックブログ
                                                                        • 「みんなジョブズにだまされている」? エッジ/フォグの進化が必然である理由 (1/2)

                                                                          さくらインターネット研究所では、10年後の未来を見据えた研究ビジョンとして「超個体型データセンター(Superorganism Data Center)」のコンセプトを掲げている。各研究員がそれぞれの専門領域からこの世界に向けてアプローチする中で、分散システム(エッジ/フォグコンピューティング)領域の研究を進めるのが上級研究員の菊地俊介氏だ。 さまざまな業界におけるIoT活用や5Gサービス開始の動きもあり、市場ではさまざまなエッジコンピューティングのソリューションが出始めている。しかし菊地氏は、現在実用化されているエッジコンピューティングと超個体型データセンターの世界の間には「まだまだ大きなギャップがある」と指摘する。“理想の世界”を実現するためには、これから何が必要なのだろうか。 エッジとフォグの大きな違いは“タテ構造/ヨコのつながり” 菊地氏は早稲田大学大学院 理工学研究科 電子・情報

                                                                            「みんなジョブズにだまされている」? エッジ/フォグの進化が必然である理由 (1/2)
                                                                          • 自分の研究内容(DBMS実装)に関する最強の本一式揃えた - Yoshisaurのメモ

                                                                            最強の本一式 揃えたぞー!! アフィリンクとかないので純粋に揃えたことをアピールしたい。書評することになる本の予告です。他にもおすすめがあればリコメンド待ってます! 結構それぞれ高いので、学生なら大学の図書館に取り寄せてもらうか、社会人なら気前よく購入!!という感じでいいんじゃないかと思います Designing Data-Intensive Applications 分散システムといえば!!!!この本一択!!! 一応日本語もある。一般的なエンジニアにもおすすめされている本 イノシシ本と呼ばれている https://www.amazon.co.jp/-/en/Martin-Kleppmann/dp/1449373321 Transaction Processing Concepts and Techniques トランザクション技術といえば...この本!! といっても当初は辞書みたいに使う

                                                                              自分の研究内容(DBMS実装)に関する最強の本一式揃えた - Yoshisaurのメモ
                                                                            • プログラミングを独学する上で役に立った本

                                                                              最近こういう流れを散見するので私もやってみた。日本語しか読めないよって人も安心。全部日本語で読めます。 注意:初学者向けではありません。私自身プログラミングを独学する上の本です。初学者向けの本は次の記事にまとめました。 実用Common Lisp (PAIP) いいよ。 コンピュータプログラミングの概念・技法・モデル (IT Architects' Archiveクラシックモダン・コンピューティング) Ozという言語をつかっていろんな言語のパラダイムを検討していく書籍。めちゃくちゃ読んだ。すごくいいよ。 アルゴリズムデザイン (日本語) 単行本 – 2008/7/10 アルゴリズムを勉強したくて呼んだ。良いよ。読むべき。 関数プログラミング 珠玉のアルゴリズムデザイン 関数型プログラミングのアルゴリズムを勉強したくて呼んだ。すごく良いよ。 オブジェクト指向入門 第2版 原則・コンセプト (

                                                                                プログラミングを独学する上で役に立った本
                                                                              • GraphQL Gatewayはフロントエンド開発を幸せにする

                                                                                はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド(ウェブアプリケーション、モバイルアプリケーションなど)は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API(REST、gRPCなど)を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ

                                                                                  GraphQL Gatewayはフロントエンド開発を幸せにする
                                                                                • 今年読んだ技術書籍(2019年)

                                                                                  今年読んだ技術書籍やレポートなどをざっくりまとめてる.Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に. Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている. 今年発売されたので良かったのはProgramming Kubernetes.この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている.昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある.Kubebu