aba技術ブログ

ソフトウェア関係を中心にした技術ブログ

Spring Boot + Open Feignで同一インターフェイス内のメソッド単位でタイムアウトを設定する

先に結論

feignで定義したインターフェイスでメソッド単位でタイムアウトを設定したい場合はメソッドの引数にRequest.Optionsを渡すとその値が優先された採用されます。 これにより、タイムアウト値だけを変えるためにだけに個別にインターフェイスごと定義する必要が無くなります。

Spring Boot + Open Feignを使ってタイムアウトを設定する

Spring Boot + Open Feignを使ってAPIリクエストを実装する際にタイムアウトを設定する場合、application.properties(yml)ファイルに設定を記載する方法が一番シンプルかと思います。 以下にgoogleのトップページにリクエストする例をKotlinベースで示します。

Feignのinterface定義

@FeignClient(
name = "test-feign-client",
 url = "https://www.google.com"
)
interface TestFeignClient {

    @GetMapping("")
    fun getRequestToGoogle(): ResponseEntity<String>
}

application.ymlの例

feign:
  client:
    config:
      test-feign-client:
        connect-timeout: 3000
        read-timeout: 5000

TestFeignClient.getRequestToGoogle を呼び出す際に、下記タイムアウト設定でリクエストすることができます。

connect timeout 3秒
read timeout 5秒

同一Feign Clientインターフェイスで複数メソッドを定義すると同じタイムアウト値が採用される

Feign Clientインターフェイスで複数メソッドを定義すると、同じタイムアウト設定が適用されます。例えば以下のように追記分の getRequestToGoogleOnceAgain を呼び出すと上記と全く同じ値がされます。一方で実運用を考えると複数のAPIにリクエストする場合にAPIごとに個別のタイムアウト値を設定したいケースがあるかと思います。 その場合上記の方法に習うと、個別のinterfaceを定義しapplicaiton.ymlに追記する必要があります。

@FeignClient(
name = "test-feign-client",
 url = "https://www.google.com"
)
interface TestFeignClient {

    @GetMapping("")
    fun getRequestToGoogle(): ResponseEntity<String>

　// 追記
    @GetMapping("")
    fun getRequestToGoogleOnceAgain(): ResponseEntity<String>
}

同一インターフェイス内のメソッド単位でタイムアウト値を設定する

メソッド単位でタイムアウト値を設定する方法がOpen Feign 10.3.0 github.com

からサポートされ、 メソッドの引数にfeign.Request.Optionsを渡してタイムアウト値が設定できるようになりました。 以下に例を示します。

@FeignClient(name = "test-feign-client", url = "https://www.google.com")
interface TestFeignClient {

    @GetMapping("")
    fun getRequestToGoogle(): ResponseEntity<String>

    // 引数を追加
    @GetMapping("")
    fun getRequestToGoogleWithOptions(options: Request.Options): ResponseEntity<String>
}

getRequestToGoogleWithOptionsに引数としてRequest.Optionsを追加しました。このため、ここで渡された値が優先してタイムアウト値として採用されます。

呼び出し方の例としては以下になります。

                testFeignClient.getRequestToGoogleWithOptions(
                    Request.Options(
                        1000,
                        TimeUnit.MILLISECONDS,
                        2000,
                        TimeUnit.MILLISECONDS,
                        false
                    )
                )

よってこの例では以下のタイムアウト値が使われます。

connect timeout 1秒
read timeout 2秒

この方法でタイムアウト値を変えたいだけなので個別にインターフェイスファイルや設定を記述せずに済みます。

キーボード2台運用を卒業し自作キーボード左右分離式にMint60

パソコンのキーボードは両手が離れた然るべき

一般的なパソコンのキーボードはすべてのキーが一つの筐体に収められており、それを両手で打つ人がほとんどかと思います。一方で世の中にはそれを良しとせず、中央付近で最優に分離して利用可能なキーボードがあります。市販品だとBAROCCO MD770や ergodox-ezが該当します。これらのキーボードを利用すると左右の腕を開いて置けるため結果として胸が開き肩こりが楽になるという効用があります（個人差がもちろんある）

【マラソンクーポン有り】 MISTEL MD770 Barocco 英語 US配列 85キー 左右分離型 メカニカルキーボード CHERRY MX 赤軸 # MD770-RUSPDBBA1 ミステル (キーボード) [PSR]

【マラソンクーポン有り】 MISTEL MD770 Barocco 英語 US配列 85キー 左右分離型 メカニカルキーボード CHERRY MX 赤軸 # MD770-RUSPDBBA1 ミステル (キーボード) [PSR]

  

分離式を探すも好みの打鍵感に巡り会えず2台同時運用の道へ

そのため自分も分離式キーボードを利用したかったのですが、既製品で自分の好みに合う打鍵感のキーボードが見つけられず、フルキーボードを2台机に並べて使うという運用をしていました。

個人的な好みとして、静電容量式で35g程度の押下圧な静音タイプのキーボードが好みでした。

そのためRealForce, HHKN2 Professionalと渡り歩き最終的にこの2年ぐらいはNiz Plumキーボードを2台購入しそれを両方同時に利用するという形に落ち着いていました。

東プレ R2TL-JP4-BK(ブラック) 有線REALFORCE TKL 日本語配列91キー(かな無し)

東プレ R2TL-JP4-BK(ブラック) 有線REALFORCE TKL 日本語配列91キー(かな無し)

AKEEYO NiZ 静電容量無接点方式 パソコン用キーボード キーボード　ゲーミングキーボード MINI 小型 英語配列 刻印 有線 WINDOWS/MAC 両対応 左FN＋右FN プログラマブル ゲームモード 日本語マニュアル 66キー

AKEEYO NiZ 静電容量無接点方式 パソコン用キーボード キーボード　ゲーミングキーボード MINI 小型 英語配列 刻印 有線 WINDOWS/MAC 両対応 左FN＋右FN プログラマブル ゲームモード 日本語マニュアル 66キー

 

しかし、テンキーレスのキーボードとはいえ2台ともデスクに置いているとデスクの上が散らかってしまうという問題がありました。

そこで改めて分離式キーボードについて調べていると、gatelonのスイッチで静音タイプでかつ押下圧35gと軽いスイッチが発売されていることを発見しました。

市販品ではこのスイッチを搭載した分離式キーボードは見つけられなかったためゆかりキーボードファクトリーさんの分離式キーボードの組み立てキットであるMint60をこのスイッチで組み立てることにしました。

 

Mint60の組み立て

ゆかりキーボードファクトリーさんで基本セットを購入し、キーボードのスイッチは遊舎工房さんで購入した。

eucalyn.shop

はんだ付けが自分で行う必要があるが工具類が一切なかったのでAmazonで購入し買い揃えました。

何度かのトラブルに見舞われながらもテスターを使いながら導通と短絡を丁寧に確認しながら再配置して作成が完了した。

キーキャップは引退予定のNizキーボードがとりあえず借りてきて装着した。結果としてメカニカルキーボードの中では軽いタッチで比較的音も静かなキーボードを作成できました。

ありもののキーキャップを利用したのでキー間に不自然な隙間が生まれているが追々どうにかしたいです。

若干チャカチャカ音が気になるのと静音リングなるものあるらしいので今度試したみたい。

Mint60完成写真

Mint60完成写真

 

 

 

 

 

 

Zero Trust Networkまとめ

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計 まとめ

概要

本書は原著が2017年に公開され、日本語翻訳版は2019年に出版されました。著者らは2014年ごろから本の内容にあたるゼロトラストネットワークという考え方についてカンファレンス等で提唱する活動を始めています。

近年システムのネットワークをNATや個別のサブネットワークで区切り、安全な領域とそうでない領域を分けてセキュリティの構築を考えることの限界が指摘されてきました。リクエスト元が安全（だと思っている）ネットワークからという理由だけでリクエストを信頼してしまうことには大きな課題が生まれます。また、スノーデン事件が指摘したことの一つにたとえデータセンター内のネットワークであってもそこは盗聴されている可能性を考慮すべきということがありました。これらの問題意識に対して本書はリクエスト元のネットワークを拠り所にした信頼はすべて捨て去り、すべてのリクエストに対して認証と認可を実行し、まるで内部ネットワークであったとしてもインターネットから直接リクエストされているかのようなセキュリティを敷くことを提唱しています。

境界モデルとその限界

元来システムのネットワークを設計する際に、インターネットに直接公開している部分にNATを使い、インターネット向けと内部向けでネットワークを分けることが行われています。さらに内部ネットワークに一度入ったあとのネットワーク内部のリクエストに対しては、大した認証や認可は実施せずにリクエストを許可することが往々にしてあります。例えばある社内システムにはVPNが必須で特定のネットワークからだけしかリクエストできないとします。ただし、その社内システム自体には適切なアクセス制限が施されず、VPNからのリクエストであることをベースにリクエストを許可してしまう運用がなされたりします。

ゼロトラストネットワークの考え方

ゼロトラストネットワークでは信頼の拠り所をリクエスト元のネットワークに置くことを一切認めず、すべてリクエストに対して認証と認可を行い誰かがどんなデバイスで何にアクセスしようとしているのかを検証すべきしています。

 

ゼロトラストネットワークを実現するめには

ゼロトラストネットワークを実現するめには信頼の起点としてシステムの運用者を前提とします。そのうえでシステムの運用者がデプロイしたシステムが同様に信頼できるという考え方をします。

システム内のエンティティとしてユーザー、デバイス、アプリケーションを考えます。

システムの利用者としてのユーザーはすべての利用者に対して識別と認証を行い、ユーザーが利用するデバイスはX.509証明書のような公開鍵暗号に基づく証明書を用います。またシステム内のエンティティとしてのアプリケーションに対してもクレデンシャルを発行します。

これらの構成要素に対してポリシーを設定し、ユーザーを事前に認証した後ユーザー・アプリケーション・デバイスの組み合わせに対してすべてのリクエスト認可をすることを説いています。

ケーススタディ

具体的なケーススタディとしてシステム監視モニタリングツールのPagerDutyとGoogleのBeyond Coprの例が紹介されています。