データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog
バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の
となっています。 構成図 クラスタを構成するものを図にすると以下のようになります。 この中の一部コンポーネントは次節以降で登場します。 Kubernetes基盤 クラスタの基盤部分についてどのような構成になっているのか説明します。 kubeadm クラスタの構築自体については kubeadm を利用しています。 kubeadm を利用したクラスタの構築方法については公式のドキュメントが参考になります。 Static Pod と systemd kubeadm でデプロイすると kube-apiserver 等は Static Pod で、kubelet は systemd 以下で動作するようになります。 kube-apiserver は意外にメモリを食ってしまうのでそのまま動作させているとメモリ不足になることがあります。（ありました） なので kube-apiserver と etcd の
レッドハットでインテグレーションのためのミドルウェアのテクニカルサポートを担当している山下です。 最近はマイクロサービスでシステムを開発しているという話もよく聞くようになってきました。ではそこでメッセージング、そしてKafkaを使ってますでしょうか？マイクロサービスでは何故かRESTばかりが世の中に注目されてしまうことも多いために、今回はメッセージング推しの内容にしています。 マイクロサービスではメッセージングを用いたコマンドやイベントこそ中心であって不可欠です。マイクロサービスの中でメッセージングはどのように利用され、そしてなぜ必要なのでしょうか。今回は「マイクロサービスとメッセージングのなぜ [概要編]」と題してそれを概観していきます。 Kafkaの簡単なおさらい どこでメッセージングは利用されるのか？ RESTはお手軽な解決策？ なぜマイクロサービスにメッセージング(Kafka)が必
![マイクロサービスとメッセージングのなぜ [概要編] - 赤帽エンジニアブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/707ca04fc1adae69cf6e76dabc92e34469792eec/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Ftyamashi-oss%2F20190724%2F20190724112428.jpg)
2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek（@takasek）です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています（形式手法 カテゴリーの記事一覧）。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造（モデル）を与え、そのモデルを解決の機構に落
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
［速報］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
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が本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
6/30のOffice365勉強会のEntra Verified ID特集の資料です。 分散型ID、Entra Verified IDの解説をしています。Read less
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMessaging - Choreography - EventDriven - EventSourcing - SagaPattern
［速報］「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
分散システムの課題
Amazon が 2 台目のサーバーを追加した時から、分散システムは Amazon で馴染み深いものになりました。私が 1999 年に Amazon に入社したとき、サーバーの数が非常に少なかったため、「fishy」や「online-01」などのわかりやすい名前を付けることができました。けれども、1999 年であっても、分散コンピューティングは容易ではありませんでした。また現時点で、分散システムの課題には、レイテンシー、スケーリング、ネットワーキング API の理解、データのマーシャリングとアンマーシャリング、および Paxos などのアルゴリズムの複雑さが含まれます。システムが急速に大きくなり、分散するにつれて、理論的なエッジケースであったものが定期的に発生しました。 信頼できる長距離電話ネットワークやアマゾン ウェブ サービス (AWS) のサービスといった分散ユーティリティコンピュー
玉木雄一郎（国民民主党代表） @tamakiyuichiro #国民民主党 ( @DPFPnews )代表。さぬきうどんとギョーザ定食が好きな衆議院議員（香川2区）永田町のYouTuber「たまきチャンネル」youtube.com/@tamaki-channel インスタもやってます！ ameblo.jp/tamakiyuichiro/ 玉木雄一郎（国民民主党代表） @tamakiyuichiro 世界３位の時価総額を誇る東証の終日取引停止はIT先進国とは言えない事態。日本の株式市場に対する世界からの信頼が損なわれかねず速やかな復旧を求めたい。他の取引所にも拡大しておりサーバー型ではなくシステムのブロックチェーン化など分散化を進める必要もあると思う。 news.yahoo.co.jp/pickup/6372518 2020-10-01 16:12:12
Nostr の面白さをエンジニア目線で解説してみる
はじめに 今年は、SNS でありプロトコルでもある Nostr に出会いました。2023年2月の参加でしたがもう、どういった経緯で Nostr を見付けて参加したのかすら思い出せなくなってしまいました。ここ数年、X/Twitter が API という物を開発者に触らせなくなってしまいました。僕は X/Twitter が大きくなった理由の1つが、API をオープンにした事で数多くの bot やサービスがが登場した事だと思っていて、API が自由で無くなった X/Twitter をとても残念に感じています。次第に SNS に関連する何かを作るモチベーションはさっぱり無くなってしまっていました。 そんな中で見付けた Nostr はエンジニアのオアシスとでも言える SNS だと感じました。 Nostr の思想 X/Twitter は中央集権型の SNS であり、以下の様な問題を持っています。 障害
実用 Go言語
業務プログラミングの現場でも採用されるようになってきたGo言語。文法はシンプルで学びやすいという特徴を持っていますが、複雑な要件を実現するには、プログラミング言語が提供する構成要素（文法やライブラリ）をさまざまに組み合わせる必要があります。 本書は、そんなGoを使う上でのポイントを単なる文法詳解ではなく「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点から紹介します。 構造体やインタフェースの使い方からJSON、CSVファイル、Excel、固定長ファイルの扱い方、またログやテスト、環境構築など現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」をその背景と共に教えてくれる先輩のような書籍です。 まえがき 1章 「Goらしさ」に触れる 1.1 変数やパッケージ、メソッドなどに名前を付けるには 1.1.1 変数名 1.1.2 パッケージ名 1.1.3
試験を受けるきっかけ 僕が入社した当初、資格取得を奨励していたこともあり、半ば強制でソリューションアーキテクト – アソシエイトの試験を受験させられました。今考えれば 完全にパワハラ ですよね。 それから2年後、iOS開発者として色々な案件に従事してきましたが、いろいろな領域の開発に興味が出てきたこともあって、サーバーレスアーキテクチャを採用した開発案件に飛び込みました。ちょうどその頃、 サーバーレス開発部 の立ち上げが重なり、 AWS の勉強を本格的に始めました。 SAP [期限: 2017-11-30] DOP [期限: 2017-11-30] Chatwork のタスクにこの２つが 部長 から追加されていたことは今でも忘れられません。 今考えれば 完全にパワハラ ですよね。ただ、労働基準局に駆け込むよりも「よし、やってやろう」という気持ちの方が大きかったです。取得した ソリューション
Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで - Findy Engineer Lab
自分が気づいてなかった資質を、探して、磨く 劣等感に消耗するより、目的志向で考える オープンソースコミュニティへの参画 ドメイン駆動設計とScalaが「点」となる ドメイン駆動設計との出会いと成果 遅延評価的学習法でScalaを習得 Scalaを使ってDDDを実践するスタイルを確立した 実験的に導入して結果が出れば業務での普及も進む 積み上げてきたScalaとDDDの開発スタイル Scalaコミュニティとともに 新しい挑戦で新しい「点」ができ、そして「線」につながる 「いずれどこかで点がつながって実を結ぶだろう」 過去も未来も思い切って手放し、今の自分に集中する こんにちは、Chatworkでテックリードをしている、かとじゅん（@j5ik2o）です。 今年（2020年）で48歳になりましたが、技術に前向きになったというか、本気を出したのは37歳ごろでした。遅いな……（笑）。まぁ、遅い早いが
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
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として最低限の機能を整備したにすぎず，さ
この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。（往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする） ※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・ また機会があればdidconでも開催してじっくりお話さ
はじめに タイトルは釣りです（テンプレ） はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。 ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。 社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots) 自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です！ 入社の経緯とか そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
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つ目のアルゴリズム・シャー
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）を定義したり設定したりことが、サイト
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) のパーティショニング (シャーディング
こんにちは！最近気になるニュースはスピノサウルスの尻尾の化石が発見されたこと1な、SRE部エンジニアの塩崎です。ZOZOテクノロジーズの前身となった会社の1つであるVASILYでは数多くのクローラーの開発・運用の担当をしてきました。 今回はその知見を生かして、クローラーを楽に運用するためのクラウドサービスを紹介します。 概要 データ解析を円滑に進めるためには、CSVやWeb APIなどの構造化されたデータが必要です。しかし全てのWebサイトにあるデータが構造化データを提供しているとは限りません。むしろ提供していないケースの方がはるかに多いです。そのため、Webクローラーを作成して構造化されていないWebページを解析し、構造化データを生成する必要があります。 しかし、Webクローラーの運用には数多くの「つらみ」があります。特に大量のWebページを1日1回などの頻度で定期的にクロールする際には
GitOps を使用したサーバーレス時代における最新の CI/CD パイプライン構築 | Amazon Web Services
Amazon Web Services ブログ GitOps を使用したサーバーレス時代における最新の CI/CD パイプライン構築 AWS コミュニティヒーローで、Datree.io の CTO 兼共同創設者、Shimon Tolts 氏によるゲスト投稿。彼は開発者向けのツールとインフラストラクチャが専門分野で、100％ サーバーレスの会社を運営しています。 近年、ソフトウェアの構築と配信の方法に大きな変化がありました。主にマイクロサービスに関するもので、コードを小さなコンポーネントに分割し、インフラストラクチャをコードとして使用し、Git を信頼できる唯一のソースとして利用することでこれらすべてを結び付けたのです。 この記事では、最新のソフトウェア開発の推移とさまざまな手段について説明しながら、サーバーレスの世界での選択可能なソリューションをご紹介します。さらに、現代にふさわしい便
SOAは優れた原則に基づいており、その大半はまだ有効です。それは契約優先開発、疎結合、構成可能、ステートレスなサービスであり、自律的で再利用可能です。 ESBフレームワークは、プロトコル変換、テクノロジーコネクタ、ルーティングおよびオーケストレーションメカニズム、エラー処理、高可用性プリミティブなどの優れた機能セットを提供しました。 分散アーキテクチャの進歩 SOAとESBの主な問題は、アーキテクチャと組織の両方の観点からの集中化でした。SOAの重要な原則は、サービスとコンポーネントの再利用でした。これにより、再利用を可能にするが、緊密なアーキテクチャ上のサービスカップリングを引き起こす階層化サービスアーキテクチャが作成されました。組織的には、ESBは単一のチームによって所有されていました。それによって、ミドルウェアは、スケーラビリティの観点で、さらに重要なことに急速な進化の観点で技術的お
今後は「データ指向アプリケーションデザイン」を考えよう(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
2017年にも同じタイトルの記事を書いたのだけど、その後無事にスタンフォード大学院のコンピュータサイエンス学部を卒業することができたので、前回の記事以降に取った授業について、僕なりの感想をちょっとまとめたい。 CS255 暗号入門 (2018Q1)文字通り暗号についての授業。対称鍵暗号、公開鍵暗号、メッセージ認証、一方向ハッシュ関数などのトピックについて学ぶ。プログラミングではなく理論中心の授業。 宿題では、例えばこういう手順で暗号化される通信が安全であることを証明せよ、みたいな問題が出た。こういう問題は、もし安全ではないとしたらそれを利用して安全とされている暗号（AESとか）を破れてしまう、みたいな背理法で証明を行う。そういう巧妙な証明を考えるのは結構面白かった。あるいは逆に、このように暗号化された通信方式の穴を見つけよ、みたいな問題も出た。 AESやSHA256そのものがなぜ安全と思わ
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:
AWS Lambdaの高速なコンテナロードの仕組み | CyberAgent Developers Blog
CTO統括室の黒崎(@kuro_m88)です。今回はAWS Lambdaの高速なコンテナロードの仕組みについて紹介します。 AWS Lambdaはサーバレスなマネージドサービスであり、難しいことを知らなくてもユーザ(私たち)は簡単にアプリケーションをホストでき、簡単にスケールします。 ユーザから見るとシンプルですが、その裏側では様々な仕組みがあったり最適化が行われたりしています。 マネージドサービスの裏側を必ずしも知る必要はありませんが、仕組みを知っておくとより使いこなせるはずですし、自信を持って技術選定ができるはずです。(そして何より裏側を知ることは楽しい！🤗) 本記事はUSENIX ATC 2023で発表された論文「On-demand Container Loading in AWS Lambda」の内容に基づいて、読んでいて面白かったポイントをまとめています。 On-demand
こちらはエムスリー Advent Calendar 2022 Advent Calendar 2022の延長戦31日目の記事です。 エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。検索とGoが好きです。 検索エンジニアってどこで採用できるの？ という話を至る所でよく聞きます。僕自身も、自ら検索エンジニアと名乗るエンジニアにほとんど出会ったことがありません。やはり、世の中の検索にまだ魅了されていないエンジニアを情報検索の世界に引き込むしかないので、今回は僕が情報検索にハマった経緯を紹介することで一人でも多くのエンジニアを情報検索の世界に引き込めればと思います。 情報検索との出会い 情報検索の探索 発展 まとめ 情報検索との出会い 僕が最初に情報検索に出会ったのは前職の白ヤギコーポレーションでした。そこではElasticse
Amazon SQSでFIFOだからってシステム全体が Exactly-Once になると思ったら大間違いだっていう話 - Smoky God Express
TL; DR Amazon SQS で Exactly-Once なキューを使おうとも冪等な処理を書くべき キューが Exactly-Once であるという性質はシステム全体が Exactly-Once になることを保証できない 結局マルチデータソースへの書き込みの問題が残る Designing Data-Intensive Applications (邦訳: データ指向アプリケーションデザイン） が良書でした 邦訳は未読1ですが原著の内容がいいのできっとだいじょうぶでしょう Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 作者: Martin Kleppmann出版社/メーカー: O'Reilly Media発売日: 2017/
さくらインターネット研究所では、10年後の未来を見据えた研究ビジョンとして「超個体型データセンター（Superorganism Data Center）」のコンセプトを掲げている。各研究員がそれぞれの専門領域からこの世界に向けてアプローチする中で、分散システム（エッジ／フォグコンピューティング）領域の研究を進めるのが上級研究員の菊地俊介氏だ。 さまざまな業界におけるIoT活用や5Gサービス開始の動きもあり、市場ではさまざまなエッジコンピューティングのソリューションが出始めている。しかし菊地氏は、現在実用化されているエッジコンピューティングと超個体型データセンターの世界の間には「まだまだ大きなギャップがある」と指摘する。“理想の世界”を実現するためには、これから何が必要なのだろうか。 エッジとフォグの大きな違いは“タテ構造／ヨコのつながり” 菊地氏は早稲田大学大学院 理工学研究科 電子・情報
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Managed Kubernetesサービス開発者の自宅k8sクラスタ全容
マイクロサービスとメッセージングのなぜ [概要編] - 赤帽エンジニアブログ
ゼロから学んだ形式手法 - DeNA Testing Blog
ウクライナ侵攻とインターネット – JPNIC Blog
【2024年】ITエンジニア本大賞まとめ - Qiita
今なら間に合う分散型IDとEntra Verified ID
サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
日本ブロックチェーン協会ユーゾー代表理事曰く「マイナンバーにブロックチェーンⓇを」「しかもASCII」
iOSエンジニアとして入社した僕が AWS認定資格 11冠 になった話 | DevelopersIO
“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳
設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog
分散型IDに関する10の所感（2022年2月版）
ZOZOテクに入社してもうすぐ1年半になるので、リアルな話をしたい - inductor's blog
正しいクラウドはある意味で遅い - Software Transactional Memo
モダンなシステムにSLI/SLOを設定するときのベストプラクティス
クローラー運用を楽にするためのクラウドサービス比較 - ZOZO TECH BLOG
サーバーレス時代のKubernetesワークロード：アーキテクチャ、プラットフォーム、トレンド
スタンフォードのコンピュータサイエンスの授業の感想（後編）｜Rui Ueyama
2022年にやったこと - k0kubun's blog
ただのソフトウェアエンジニアが検索エンジニアになるまで - エムスリーテックブログ
「みんなジョブズにだまされている」？ エッジ／フォグの進化が必然である理由 (1/2)