タグ

2019年6月1日のブックマーク (5件)

  • API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ

    ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt

    API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ
  • SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog

    SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。

    SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • railsdmでマルチテナント・ウェブアプリの話をしました - Islands in the byte stream

    railsdm.github.io 発表:「マルチテナント・ウェブアプリケーションの実践」 一文でまとめると「HTTPのリクエストごと、あるいはjobの実行ごとにストレージの名前空間違うから気をつけような!!」ってのを常に意識する必要がありますって話でした。 なおElasticsearchのnamespacing v2はまさに先週の話なのですが、遅くなったというのは勘違いでした。 というのも少しだけ日付けをずらしてfuzzy searchの実験もしており、それがパフォーマンスに悪影響を与えていたようです。fuzzy searchはノイズが増えるので結局無効にすることにしたため、トータルではnamepsacing v2はnamespacing v1よりパフォーマンスがよくなっています。 またブコメでも指摘されているように、テナント横断のことをやり始めるとまたいろいろと新しい課題がでてくると思

    railsdmでマルチテナント・ウェブアプリの話をしました - Islands in the byte stream
  • マルチテナントアーキテクチャについて - コンポツさん

    SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者(ここではテナントと呼ぶ)が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少

    マルチテナントアーキテクチャについて - コンポツさん