サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
yuichi1004.hatenablog.com
ひょんなことからアーキテクト職として本格的に働くことになって、早くも1年と少しが経った。まだまだ勉強することばかりだが、一つ分かったことがある。 アーキテクトというのはやはり難しい。そして、それはアーキテクトとしての意思決定が文脈的だからである。 文脈の中に生きる意思決定 例えば、以下のような状況下での意思決定を考えてみる。あなたは新しい Web サービスを立ち上げることになった。そのための技術選定とアーキテクチャ設計を行っている。 そのサービスは著名なインフルエンサーとのコラボレーションを基軸にしていて、インフルエンサーが SNS 上で集客を行うと、突発的にリクエストが集中することが予測されていた。 一方で、なにもない時に定常的なトラフィックはそれほど想定されていない。必要なときにしなやかに、素早くシステムをスケールアウトする必要がある。ビジネスロジックはそれ程難しくない。サービスから得
今日、ありとあらゆる企業がクラウド移行を果たし活用している。 こんな今だからこそ、オンプレ時代の知識が大事だという話をしていきたい。 問題 過去の経験から、一つ具体的な例を上げて話そうと思う。 以下のようなシステム構成において、System A から System B への通信が定期的にタイムアウトするという問題が発生していた。 この問題の分析は難航していて数々の担当者があたっていたが、ついに解決されないまま数年間放置されていた。 問題の規模がそれほど大きくなく、業務影響が大きくなかったことも放置されていた原因の一つであった。 しかし、サービスが成長するにつれて、いよいよ無視するわけにも行かなくなってきていた。 System A の担当エンジニアは言う。 「タイムアウトのためのパラメターは確認したし、思いつく限りのログを取ってみた。ログを確認したところ、System B からのレスポンスが
開発組織のマネジメントについて議論していると「専門性人材が活躍できる職場づくり」「専門性人材のためのキャリアパス」といったフレーズを良く耳にする。『専門性人材=技術的』という無意識の仮定をおいてしまっていないだろうか。一昔前ならこの仮定は成り立っただろう。だが、今となっては小学校からプログラミング教育を実施するし、専門学校はたくさんある。転職市場には新卒教育で技術的スキルを身に着けた人材があふれている。もはやプログラミングやシステム開発の知識は専門的ではない。リテラシーとなりつつある。こうした背景の中で、『専門性人材=技術者』と仮定してしまうと技術者キャリアの本質を見落としてしまうのではないかと思う。 特に思うのが、技術的ゼネラリストの重要性である。ココの人材が組織に一人いるだけで組織が生み出すシステムの全体感がぐっと高まる。この記事では技術的ゼネラリストとその重要性について議論する。 開
はじめに この記事では、従来型の組織にアジャイル開発を導入しようとして引っかかる、よくある「障害」とその解消のための方法について話します。 最近シニアエンジニアとして、新しい開発チームの立ち上げに関わる機会が増えてきました。 自分も含めて周囲のエンジニアやマネジャーが「アジャイル」を導入しようとして、うまくいくケースとうまくいかないケースがあります。上位のマネジャーの理解が得られなかったり、逆に現場エンジニアたちの理解が得られなかったり理由は様々ですが、一言で言うなら「組織」に理解がされないということです。自らの失敗を分析したり周囲の話を聞いていると、アジャイルの導入に失敗するケースは往々にして「組織」が何を求めているのか適切に理解して運用できていないケースが多いように思います。つまり組織が「アジャイル」を認めていないわけではなくて、適切にアジャイルな開発が運用できていないから組織の期待に
最近 Cloud Spanner のベータ公開によって話題の Spanner。 気になっていたので論文を読んだり勉強会などで情報収集していました。日本語のリソースもそこまで多くないので、調べてわかったことを纏めておきます。 簡単にまとめると特徴は以下のとおりです。 Bigtable / Datastore と類似したアーキテクチャをとっており Tablet 群にデータを分散保存している ↑の仕組みであるの上に Lock Table を実装して同期処理のためのロックを処理している さらに↑の仕組みの上に分散トランザクションマネジャーを実装し、グループ横断のトランザクションを管理する 以下で、細かい説明を続けていきます。 Spanner の全体構成 Universe と Zone Zone と Spanserver Spanserver の構成 Spanserver と Replica Rep
App Engine を利用していると、時たま何かに引っかかったように処理が詰まることがあります。こんな時にはもちろん StackDirver Trace を使ってボトルネックを探ったりするわけです。 しかしながら時に、何の RPC を呼び出しているわけでもないのに、何故か処理の開始が遅い場合や、レスポンスを返すのが遅いということがあります。 よくありがちな理由が、リクエストが殺到して新規インスタンスがスピンアップするときに処理が遅れることです。私の周りでは良く「スピンアップに引っかかる」と言っています。しかし、具体的に何が起こっているのか、本当にスピンアップが起因しているのかは曖昧のままでした。そのため、今回、真面目に調べてみることにしました。 Request Queue を理解する App Engine がスケールする仕組みを詳しく知るには Pending Request Queue
App Engine の Scale Type には Manual Scaling / Basic Scaling / Auto Scaling の 3 種類があります。 https://cloud.google.com/appengine/docs/go/an-overview-of-app-engine#scaling_types_and_instance_classes このうち Basic Scaling と Auto Scaling はいずれもユーザーからのリクエスト数に応じてインスタンス数が増減するものでありますが、果たして何が違うのでしょうか。気になったので調べてみました。 本稿では、Basic Scaling と Auto Scaling の基本性能に差があるのか調べてみたという話をします。 なぜ Auto Scaling を選ばないのか Auto Scaling をあえて
Pattern 1: エラーを値として定義する Pattern 2: 動的にエラー値を生成する Pattern 3: 独自エラー型を定義する Pattern 3 (番外編): 独自エラー型はかならず error interface で返す 結論 今回は go のエラーハンドリングのパターンについて書いていきたいと思います。以下の Post とかなり被る部分があるので合わせて参考にしてください。 Error handling and Go - The Go Blog Pattern 1: エラーを値として定義する 一番単純な方法としてエラーを値として定義してしまう方法があります。 var ErrNeedCake = errors.New("error - i need cake not this") func Func1(name string) error { if name != "ca
こんにちは、むらたです。Advent Calender 初めてのチャレンジです。 自分は職務でよく、App Engine で Microservices 構成をとった開発をやります。例えばこんな感じの構成です。 DeNAでのGCP活用事例とGCP NEXTでの事例紹介 — Mobage Developers Blog この時困るのが、各サービスのゲートウェイの設計です。App Engine の場合、各サービスにそれぞれ appspot.com ドメインが振られるので、例えば example-dot-project-id.appspot.com のようなドメインが振られます。このサービス用のドメインで直接アクセスすれば良いという話もありますが、そうも行かない場合もあります。同一のドメインで API をさばいたり、コンポーネントとパスの構成を柔軟に行いたい場合などです。 dispatcher.
このページを最初にブックマークしてみませんか?
『yuichi1004.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く