だらだらと思いついたこととか書くブログ

エンジニア的なネタとか備忘録とかを書いていく予定

API呼び出しをRestTemplateからWebClientに切り替えた話

どんな話?

spring-bootで作成されているマイクロサービス間のAPI通信のクライアントをRestTemplateからWebClientに切り替えてみましたという話。

なぜ切り替えたのか、どのように対応しているのかといった内容を書きます。

なぜ切り替えたのか?

ビジネスロジックの中でいくつか別サービスへの通信を行っているが、いくつか非同期で通信を行える箇所があった。

メッセージキューを利用したりと徐々に非同期化を図っていたが、今回のケースでは解決法としてWebClientを利用するのが適してそうなこともあり試してみた。

そもそもRestTemplateは2022年4月現在でメンテナンスモードとなっており公式でもWebClientの利用が推奨されていたため、近い将来切り替えたいという話も上がっていた。

切り替え前の状況

ビジネスロジック内の1処理としてhttp通信での別サービスの呼び出しを行っている。

この通信自体は即時性が求められるものではなく、非同期での連携で問題ないものではあったが同期的に通信処理を行っていた。

ただし連携開始してから、たびたび通信が不安定になるケースが発生しており、これに起因しての不具合が発生する事がわかった。

そのため非同期連携に切り替えようと思いどんな方法が良いかなと考えたところ、WebClientでノンブロッキングでの連携が適していると考え切り替えを実施した。

切り替えについて

実現したいこと

  • 非同期、ノンブロッキングでのAPI呼び出しを行いたい
  • タイムアウト発生時にはリトライを実施したい(通信状況が不安定なケースでもリトライで復旧するケースも多いため)

実装例

APIクライアントの定義例

@Component
public class ServiceApi {

  private final WebClient webClient;

  public ServiceApi() {
    this.webClient =
        WebClient.builder()
            .baseUrl("URL")
            .build();
  }

  public Mono<Void> create() {
    log.info("cacheUserPlan request={}", request);
    return this.webClient
        .post()
        .uri("URL")
        .retrieve()
        .bodyToMono(Void.class)
        .retryWhen(
            Retry.fixedDelay(2, Duration.ofSeconds(5))
                // タイムアウトエラーが発生した場合には5秒間隔でリトライを行う(2回までAPI呼び出しを試みる)
                .filter(
                    throwable ->
                        throwable instanceof WebClientRequestException
                            && (throwable.getCause() instanceof ConnectException
                                || throwable.getCause() instanceof TimeoutException)));
  }
}

API呼び出し側の実装例

今回はビジネスロジックからの該当のAPI呼び出し部分のみノンブロッキングにしたかったため呼び出し側でsubscriberを利用 (Monoのままプレゼンテーションでレスポンスはしない)

ServiceApi
    .create()
    .subscribe(
        response -> {
            // API呼び出しが成功した場合の処理
        },
        exception -> {
            // API呼び出しでエラーが発生した場合の処理
        });

参考にさせていただいた情報

リトライのテストについて

リトライ周りのテストをどう書くのが良いか分からず少しハマった。

調べてみた限りMockWebServerを利用してモックサーバにAPI接続して試す方法が良く紹介されていたのでそちらを利用してみることにした。

参考にさせていただいた情報

今後について

切り替え後はしばらく様子を見てエラーハンドリングやリトライ設定などを今後必要に応じて見直していきたい。

リトライについてはjitterを利用したexponential backoffの利用なども考えていきたい。

RestTemplateを使ったAPI接続で並列処理数が上がらずにハマった話

どんな話?

RestTemplateを使ってのAPI呼び出しで複数スレッドでの並列呼び出しを行っているのに、なぜか呼び出された側で5並列まででしか処理をされていないという事象が発生して調査してみましたという話。

色々試してみたりで新たに学んだことがあったので備忘録兼ねてまとめた内容。

状況

※以下、API接続の呼び出し元のとなるサービスを「サービスA」、APIを提供しているサービスを「サービスB」と表記します

  • サービスA、BともにJava&spring-bootで作成されているアプリケーション
  • サービスAでは少なくとも10スレッドでリクエストしようとしているアプリケーションのログを確認
  • サービスBでは5を超えるスレッド数で処理できているAPIも存在している様子
  • サービスAではRestTemplateはデフォルトの設定で利用
  • サービスAではサービスBと別のサービスへのAPI接続も行っており、そちらではapacheの httpcomponentsのhttpclientを利用していた

調査してみて分かったことと原因

  • サービスAのRestTemplateでは「javaのHttpURLConnection」ではなく、「apacheのhttpcomponents」が使われるようになっていた
    • debugでRestTemplateの設定内容などを確認してみて判明した
    • ここは推測だがdependencyとして「apacheのhttpcomponents」が定義されている場合にRestTemplateをデフォルトで利用すると、「apacheのHttpComponents」のhttpclientが利用されるようになるらしい
    • 試しにapacheのhttpcomponentsをdependencyから外してAPI接続してみたところ、サービスBの処理が10スレッドで走った
  • RestTemplateでapacheのhttpcomponentsをデフォルト設定で利用する際に、connection poolの設定の中でmaxPerRoute)という値があり、これが5で設定されるようになっていた
    • そのため、同一接続先への接続上限数が5になっており、サービスBで最大5並列まででしか処理されていなかった
    • 上記のmaxPerRouteの設定を試しに10に変更してみたら、サービスBの処理が10スレッドで走った

まとめ

  • 複数スレッド走らせる場合のテストはちゃんとやらないとダメ(特に今回はローカルでも再現可能な事象だったこともありこれに尽きる)
  • IDEデバッグ機能の活用大事
  • RestTemplate理解したつもりになっていたけどよく分かっていなかった・・
    • ドキュメント見たり、挙動見たり今回のことを通して学びました

その他参考になったページ

terasolunaorg.github.io

最近の仕事や環境で思っていること

昨年の2月中頃からリモートワーク中心になり1年強。

この1年で所属しているチームのメンバーが変わったり、様々なタスクやプロジェクトを進めたりと日々過ごしていく中で、当然ながら色々感じたことや思うところがあった。

近々チーム内での振り返りをしましょうという話があるが、まずは自分が感じていることなどを一度整理してみたいと思っていたこともあり、 思いついたことなどをつらつらメモがてら書いてみます。

ずっとアタマにはあったけどここで急にやってみようと思ったのは、アジャイルな開発とチームづくりの内容に触発されたのがきっかけの1つ。

チームとプロジェクトの進め方について

チームはバックエンドのAPI開発・運用を担当しているチーム。

メンバーは7人いて、ここ1年くらいで新しくチームに加入してくれたメンバーとそれ以前から在籍しているメンバーが半々くらい。

2週間スプリントでアジャイルで開発を進めているが、担当プロダクトはSoRでわりとウォーターフォールよりな開発が必要とされている部分が多いように感じている。

主要な登場人物としては、PO(Product Owner)と開発チームメンバーがおり、POは1人で複数プロダクトを兼任しているような体制。

開発は複数プロジェクトをチーム内で分担しながら進めているような状況。

チーム内でリーダーという役割・肩書の人はおらず、ファシリテート役をローテーションで回すなどしている。実質、リーダー的な役回りをしてくれている人がいたりもするが、その人にだけ負荷がかからないような仕組みづくりができるようチーム内で心がけている。

最近の取り組みや役割について

以前はチーム全体で複数プロジェクトで必要な対応をばーっと並べて、進めたいタスクを取っていきやっていくスタイルだったが、複数プロジェクトを並行して効率的に回していくための取り組みとして、プロジェクトごとに主担当とサブ担当みたいな割り振りをして、各自で担当プロジェクトの対応を中心にタスクを取っていき進めていく手法を採るようにしていきましょうという話になっている。

また所属チームは開発・運用はもちろん、プロジェクトの優先順位の調整や要件定義、プロジェクトリードのような立ち回りも担っていることが多い。

最近感じていることや課題

プロジェクトの進め方と役割分担

前述のようにプロジェクトに対しての関わり方を変えたことで、以前に比べてそれぞれのプロジェクトに専念できるような仕組みづくりとなってきた一方で、テックリードやマネージャーなど役割の人がいないため、プロダクト全体や他プロジェクトとの関係などに気を配る人、というのを役割として明示的に担っている人がいない状態となっている。

そのため中心的に動いてくれている人や、やれる人が全体の把握などを"暗黙的にしている"という状態になっている。

この暗黙的というのが難しく、出てきた課題をどうするか、ここからどうプロジェクトを進めていくかなどといった、プロジェクトを進める舵取りをしていく中での"関係者"を誰にするか、というところなどで頭を悩ませる場面もたびたびあり、結果としてチームがうまくスケール出来ていないのではと個人的に感じる場面がある。

かと言って、そこを完全に分業してしまうと、全体を把握できるメンバーが新たに出づらくなる、担当プロダクトの全体感が見えづらくなるという弊害もあるように感じているので、この辺りのバランスをどこに持っていくのか、というのが非常に悩ましい課題だと感じている。

プロジェクト内での役割と要求ハードルが高くなっているのではという危機感

次にプロジェクト内での役割についてだが、暗黙的かつ必要に応じて担当している"役割"みたいなものが大きく、あるプロジェクト内でのあるプロダクトの担当メンバーという立ち位置だけでなく、プロジェクトリード的な立ち位置も一緒にこなす必要が出てくる場面がたびたびある(というより増えてきている)。

これにより"主担当を持つこと"に対して心理的なハードルも高くなってしまっているように感じている。

今後について

プロジェクトの進め方と枠割分担については、今後も手探りで進めていきながら「ちょうど良いバランス」を模索して、調整しての繰り返しでやっていくのかなという感じ。

ここに書いていること、想っていることは個人的な主観たっぷりの考え方なので、他の人達がどう感じているのかなどはちゃんと聞いてみたい。

プロジェクト内での立ち位置などについても、個人的な考えなので、これが自分だけの意見か、他にも同様の課題感を持っている人がいるのかは一度ちゃんと確認しておく必要がありそう。

その上で"やっぱりこの課題があるしなんとかしなくては"となった場合は、「では、何がいま一番解決したい課題なのか」を探っていくところから地道に活動していくのかなと想像している。

年齢的にもそういった立ち回りをしていくことも求められていると思うので、よい"チームづくり"を実践していけるように取り組んでいきたい。

springアプリケーションのORマッパーの比較メモ

Kotlin + spring-bootのアプリケーションでのDBアクセスをどのライブラリを使って行うが良いかという課題があり、

簡単なコードを書いていくつか試してみたのでそれについてのメモ

Java ORマッパーの選定ポイントのスライドを参考にさせていただき、

の3つについて比較を、1:Nの2テーブルのみの簡単なCRUD APIを使って実施してみた

spring-data-jpa

spring-bootのORマッパー=JPAというイメージもあり、ちょっとしたwebアプリを書く際などに今まで利用していたのがこちら。

以前はspring-jdbcでゴリゴリSQLを書いていたことも合ったので「それに比べてDBアクセスが楽になった」という印象がある反面、アノテーションマッピングの仕方、JPQLの使い方など使うにあたって学習が必要なものが多いことや、複雑なクエリを書こうとしてN+1問題などにぶち当たったりと使っていく上での課題も多く、自分が使いこなせるようになるにはハードルが高いなという感じがあった。

感想

  • (利用経験での慣れが大きい気もするが)1:NやN:Nなどのマッピングアノテーションで対応できる(ただし方法がいくつかあり、どういった場面でどれを使うのが良いのかの選択が難しい)
  • ページングの実現も簡単
  • (DDDを使っている場合)集約ルートから、関連エンティティをgetter経由で取得できるのでコード量が少なくできる
  • N+1問題や3つ以上のテーブルのJOIN FETCHができない。意図していないクエリが生成されることもマチマチという課題がつきまとう

エンティティのコード例

1側

@Entity
data class Team(

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val teamId: Long? = null,

    val name: String,

    val type: String,

    @Version @NotNull val version: Int = 0

) : Serializable {

    @OneToMany(mappedBy = "teamId", cascade = [CascadeType.ALL])
    var members: MutableList<Member> = mutableListOf()
}

N側

@Entity
data class Member(

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val memberId: Long? = null,

    val firstName: String,

    val lastName: String,

    val teamId: Long,

    @Version @NotNull val version: Int = 0

) : Serializable {
}

spring-data-jdbc

spring-data-jpaと似たような書き方で かつシンプルに使えそうという印象を持ったので試してみたのがこちら。

アノテーションマッピングの仕方がほとんど同じことや、CrudRepositoryが使えるためfindByIdやfindAll,saveなどはそのまま使えるので新しく覚えることも少なくコード量もjpa同様に少なくて済みそうな感じだった。

感想

  • spring-data-jpaと同じような感じで使えるため心理的ハードルが低い(個人的に)
  • マッピングの仕方が違うことやLAZYフェッチが出来ないため、JPAに慣れている場合はそこの注意が必要になりそう
  • LAZYフェッチがないなどJPAに比べてシンプルなためN+1問題などに悩まされることはなくせるor減らせそう
  • (手元では試せていないが)ページングについては対応できていないような記述、記事を見かけたのでページングを手軽に使うことは出来無さそう
  • 情報もまだ少なく、上記のページングの話も含めてまだ、これから機能や安定性が整ってくるという印象を受けた(シンプルなアプリであれば充分だとは思うが)

エンティティのコード例

1側

@Data
data class Team(

    @Id
    val teamId: Long? = null,

    val name: String,

    val type: String,

    @Version @NotNull val version: Int = 0

) : Serializable {
    
    @MappedCollection(idColumn="team_id", keyColumn="team_id")
    var members: MutableList<Member> = mutableListOf()
}

N側

@Data
data class Member(

    @Id
    val memberId: Long? = null,

    val firstName: String,

    val lastName: String,

    val teamId: Long,

    @Version @NotNull val version: Int = 0

) : Serializable {
}

jooq

参考のスライド内では「クエリビルダー型」と分類されていたライブラリの1つ。

spring-data-jpaとかに比べると記述は増えるが、よりSQLに近い書き方ができる一方で、JDBCのように生のSQLを書く必要はないという感じなので、バランスがよくJPAで抱えていた課題を解決しつつ、エンティティの自動生成などを活用することでDBへの変更にも追随しやすい、というメリットがありそうと考えて試してみた。

DDD X CQRS - 更新系と三焦経で異なるORMを併用して上手く行った話などを見る限り、DDDにも活用できそうなことも試してみたいと思った理由の1つ。

感想

  • spring-data-jpaに比べると記述量は多くなるが、クエリで条件や取得したい情報を明確に定義できるのは良いと思った
  • エンティティの自動生成などプラグインを活用することで、開発や運用もだいぶラクにできそうという印象を持てた
  • (自分の学習不足が大きいが)2つ以上のテーブルを結合する場合などの書き方がよく分からなかったし、それ専用のDTOクラスのようなものを用意する必要がありそうに感じた
  • 1:NのテーブルでNの関連をどう定義するばよいのかが分からなかった

エンティティのコード例

1側(関連エンティティの表現はたぶん間違っている)

@Data
data class Team(
    
    val teamId: Long? = null,

    val name: String,

    val type: String,
    
    @NotNull val version: Int = 0

) : Serializable {
    
    var members: MutableList<Member> = mutableListOf()
}

N側

@Data
data class Member(
    
    val memberId: Long? = null,

    val firstName: String,

    val lastName: String,

    val teamId: Long,
    
    @NotNull val version: Int = 0

) : Serializable {
}

2021年1月の最近とやってみていること

2021年になって気づけば1月も2/3が過ぎた頃

去年からリモートワーク中心になって時間が増えた分インプットは少し頑張れた一方で、アウトプットが全然だった。

なので今年は月に1つくらいはブログなりのアウトプットを出せるようにしたい。

※2021/1/31追記あり。合わせてタイトルも少し変更

最近について

ここ最近、休日にうまく気分がのらないというか、気持ちが沈みがちであんまり何も出来ないみたいな日がたびたび出てくるようになってしまった。

持病でかかりつけの病院に行ったついでに、もし何かアドバイスもらえればくらいの気持ちで先生に相談してみたところ、

おそらくコロナ禍で生活が変わってきてしまい、「外に出ていたいタイプ」なのに外に出て行動出来ていないことがストレスになっているのでは、という話だった。

言われてみるとこの生活になって約1年が経過して、それまでと大きく変わってきたことなどで、少しずつたまってきていたものが「気分の落ち込み」という状態になって出てくるようになったという可能性が高いように思われる。

この1年での変化を振り返りつつ、ここ最近試してみていることなどを書き出して、自分の状況と気持ちについて整理してみる。

リモートワーク中心の生活になって

このコロナ禍で生活の仕方が大きく変わってきて、特に去年は外出どころか文字通り外に出ることもだいぶ少なくなってしまっていた。

去年は引っ越しがあったのでそれに伴う用事や、比較的落ち着いていたように感じていた夏〜秋あたりは休日にちょくちょく外出したりすることもあったが、

平日はほぼ毎日、自宅からの仕事で家から出ない日も多く、ジムなども春頃にやめてしまったので家で過ごす時間が格段に多くなった。

夏頃から週末にダンスのレッスンに行くことになり、かろうじて「誰かと会う」ということが出来ていたが、それ以外では友人・知人と直接会うことはほとんど無い1年だった。

特に12月くらいからはまた外出する機会も少なくなり、年末に入ってから「気分が沈む」ことが増えてきた。

平日の仕事をしているタイミングでなることは無く、週末や連休になるとそんな状態になるという感じなので、まずは気分転換が必要だろうと思い、自分なりにいろいろ試してみた。

やってみたこととこれからの過ごし方

なかなか人が集まるところへの外出はしづらかったりすることもあり、下記のような事をやってみたり、意識的に取り組むようにしてみている

  • 散歩を習慣化する
    • 落ち着いて何かを考えたりする時間が意識的に持てるようになった気がするが、30分程度の短時間であることもあってかあまり気分転換にはつなげられていないように感じている
  • 休日に妻と別に過ごす時間を意識的に作る
    • 12月頃はひとりで喫茶店に入って本を読んだりしたのは良い気分転換になったが、ここ最近は足を運びづらくなってしまった。落ち着いてきたらまた行きたい
  • 近場に買い物に出かける
    • あんまり物欲が無いのもあってか、これもうまく気分転換には繋げられてい無いような感じた
  • youtubeを見ながら体を動かしてみる
    • 先週末に妻に誘われてやってみたら意外に良かった

ちなみにやってみたのはコレ

まだこれだってものを模索中ではあるが、自分には心拍数を上げる運動が向いているのかなと思った。

あとは前々からたまに活用していたがアロマディフューザーでいい香りをかぎながら過ごすのもリラックス効果が高くわりと気に入っている。

以前のようにダンスのレッスンに行けるようになればそれも良い気分転換になると思うのだけど、 まだまだ外出しづらい状況が続くことが予想されるし、これを機に色々取り組んで新たな趣味や自分が夢中になれるものを探したい。

もし何かオススメの趣味やアクティビティ、気分転換などありましたらぜひ教えて下さい。

その後について

この記事を書いてから10日あまり(2回の土日)を挟んで自分なりにちょっと落ち着いてきた感じがあったので、備忘録と気持ちの整理を兼ねて追記

落ち着いてきた理由の考察

今後同じような状態になったときの備忘録として思いつくものをリストアップ

  1. 散歩の習慣化によるもの

外に出ること自体もあるけれども、podcastyoutubeを聞きながら何かを考えたり感じたりを1人でする時間が良かったように思う

  1. "がんばりすぎない"ことを少し達成できた

この記事を書いていた辺りは主に仕事関連でやたらと悩んでいたが、そもそもそれほど悩まなくも良いことであったし、モノによっては自分の問題でないと切り離し、その事象から少し距離をおいてみれた結果、ストレスが緩和されたように思う。

あとは悩んでいた結果、「本を読んで解決策を得られないか」、「自分がもっとうまくできれば何とかなるのではないか」と自分に過度な期待とプレッシャーを掛けてしまっていて自分を追い込んでしまっていた部分もあったように思う。ゆっくり休日を過ごすのも"自己管理"と自分に言い聞かせて、無理せず休日を過ごすようにしたのも良かったと思う。

これについては自分ひとりでは客観的に見ることが難しく妻のアドバイスと協力が大きかったように思うので感謝しか無い。

  1. 両親や兄弟とオンライン上で話す機会があった

年末年始の状況では帰省するのが怖かったこともあり、両親や兄弟と会うこともなかったのだが、たまたまオンライン上でちょっと話す機会があって実家の家族や小さい子供とリモートとはいえ話せてこれもとても良かったのかなと思う

他にもあったのかもしれないけれども思いつくのはこんなところ

嫌われる勇気の読書メモ

この本を読み始めた経緯

妻が持っていてオススメされていた本。

コロナ禍でテレワークが続く中で、当然ながらオンラインでチームのメンバーや関係者と仕事でのやり取りをする場面が増えていきました。

対面ではないやり取りをしていく際にあれこれ考えてしまったり、必要以上に発言について気にしてしまい、うまくいかないなと感じることが度々あったので、

何か改善のヒントが得られないかなと思い読んでみることにしました。

読んでみての全体的な感想

まずは本のサイズ感、厚すぎず薄すぎず、文字が大きめで読みやすいと感じました。

内容自体も青年と哲人の対話形式で話が進んでいくため、青年と自分を重ね合わせて読んでいくことで、

自分の中での考え方とアドラー心理学を元にした考え方との違いを教えてもらいながらアドバイスを受けているような感覚になり、とても理解しやすい構成になっているように思いました。

自分の経験と照らし合わせても、痛いところ突かれたなと思う箇所も多々あり、少し苦しみながら読んだ場面もあったように思います。

以下で気になった箇所や印象に残った箇所などについて書いていきます。

各章の感想と気になったキーワードなど

第1章 トラウマを否定せよ

アドラー心理学とはフロイトユングの心理学と違い目的論であるという説明から始まる章。

これまでの自分の考えとはまったく違う考え方、ここでガツンと頭を打たれたような感覚があった。

気になった箇所、キーワード

  • 変われないのは「変わりたくない」という目的のために自分で原因を作っている
  • 大切なのは「何が与えられているのか」ではなく「与えられたものをどう使うか」
  • いまの自分を"受け入れる"こと。「もしも〜だったら」という可能性の中に生きている間は変われない

第2章 すべての悩みは対人関係

全体的に気になったキーワードが多かった章だったので特に気になった箇所のみを抜粋。

対人関係が苦手な方で今まで原因論に基づいた考えで「どうすれば良いのか」を考え悩む事も多かったが、目的論を元にした考え方で自分なりに"勇気"を出してもっと変えていかないといけないんだと認識させられた章。

この章を読み、"答え"はきっと「自分の中にあるもの」なのだろうなと感じた。

気になった箇所、キーワード

  • 短所ばかりが目についてしまうのは"自分で自分を好きにならないでおこう"と決心してるから
    • これは「〜でなかったらこうであるはず」といったような可能性の中に生きることが出来るから
  • 今の自分を受け入れて、たとえ結果がどうであったとしても前に踏み出す勇気が必要
    • これを「勇気づけ」と呼ぶ

人生のタスクについて

人生のタスクとは下記の3つ。

一人の個人が社会的な存在として生きていこうとする時に直面せざるをえない対人関係のこと

  1. 仕事のタスク
  2. 交友のタスク
  3. 愛のタスク

第3章 他者の課題を切り捨てる

昔、仕事で先輩に「何にでも首を突っ込みすぎ」だとか「それは君のタスクではない」といったような指摘を良く受けていたことを思い出しながら読んだ章。

その時に注意を受けたことで変えられた部分もあるけれども、根っこではまだうまく自分のものに出来ていないんだろうなと改めて痛感させられた。

気になった箇所、キーワード

  • 他者の期待を満たす必要はない
  • 「これは誰の課題なのか」という視点から自分の課題と他者の課題とを分離する
  • 自分に出来るのは「自分の信じる最善の道を選ぶ」こと。自分がどうあるかを貫くことが「ほんとうの自由」につながる

第4章 世界の中心はどこにあるか

人の目を気にしすぎてしまうところがあるので「いかに自分が自己中心的であるのか」ということを認識させられたように感じた章。

他者への貢献をすること、そしてそれを自分で認めてあげることが「自分の幸せ」につながるという事なのかなと感じた。

ここの章の考え方は今の自分、特にオンラインでのやりとりが中心の今、とても大事にしていきたいと思った。

気になった箇所、キーワード

  • 他者からどう見られているかばかりを気にする生き方は"私"にしか関心を持たない自己中心的な生き方
  • 自らの主観によって「わたしは他者に貢献できている」と思えることで、自分には価値があると思える

第5章 いま、ここを真剣に生きる

もう一度読み返してみて"なるほど"と思えるような内容が散りばめられているなと感じた章。

1〜4の各章を自分の中に落としこんで実践できるようになってから読んでみると、また違う感じ方を出来るようになるのだろうなと感じさせられたまとめの章。

自分の弱いところ、出来ていないけど向き合っていかないといけないところが書かれているように感じた。

気になった箇所、キーワード

  • 自分に自信がないからこそ自意識過剰になる
  • 家事や育児、友人との交友や趣味などすべてに関心を寄せるべき
    • 人生の調和を欠いてはいけない
  • 人生とはダンスのようなもので「いま、ここ」が充実していればそれでよい。われわれは「いま、ここ」にしか生きられない
    • 趣味でダンスをやっていることもあり、本の中で一番、印象に残ったキーワード
    • ダンスでいうと見せるべき"いまここ"、"この瞬間"を精一杯、全力でやりきり生き抜いていくこと、の大切さというのがこの文から自分が感じたこと
  • 人生の意味は、自分が自分自身に与えるもの。困難に直面した時「これから何が出来るのか」を考えるべき

FTPのアクティブ/パッシブモードについて

目的

FTP接続のアクティブ/パッシブモードについてとデータ転送の関係などについて調べる必要が出てきて、色々と新たに知ることも多かったので備忘録を兼ねてまとめておく

FTPの接続モードと詳細

FTPについての基本情報

  • FTPは「コントロールコネクション」と「データコネクション」という2つのコネクションにより実現されている
    • コントロールコネクションは、ログイン認証やFTPコマンドの送受信を行うためのコネクション
    • データコネクションは、実際のデータを転送するためのコネクション。FTPコマンド毎にこのコネクションが作成される

アクティブモード

  • FTPサーバー側からFTPクライアントに接続する方式
  • デフォルトではコントロールコネクションにTCP/21番ポート、データコネクションにTCP/20番ポートを使用する

パッシブモード

  • デフォルトではコントロールコネクションにTCP/21番ポート、データコネクションには毎回ランダムで決まるポート番号Tを使用する
    • 通常はセキュリティ上、対象のポートレンジを指定してそのポートはファイヤウォールで許可しておくといった設定で利用される

アクティブ、パッシブ以外のモード

  • アクティブ、パッシブ以外に「EPSV(拡張パッシブモード?)」というものもあるらしい
    • EPSVは対になるEPRTとともにIPv6とNAT(Network Address Translation)に対応したコマンド
    • コントロールコネクションと同じ接続先に対してクライアント->サーバでデータコネクションの接続の確立も行う

参考

cos.linux-dvr.biz

www.binzume.net

  • telnetコマンドでFTP接続する場合に参照。それぞれのコネクションの使い分けなどの理解につながると思う

blog.naosan.jp

www.ibm.com