短納期でローンチした新サービスをJavaで開発した話/launched new service using Java

Confidential All Rights Reserved.Copyright© 2022 RAKUS Co.,Ltd.  サービス開発の理想と現実  短納期でローンチした新サービスをJavaで開発した話  2022/6/19
JJUG CCC 2022 Spring  1 

自己紹介  三田英一<Eiichi Mita>  株式会社ラクス開発統括部  <経歴>  SIにてシステム運用・開発を経験した後、  2014年に株式会社ラクスに入社  ずっと1つのサービスの機能開発や運用を担当 
@eichisanden  2 

• はじめに  • 開発体制  • Javaのバージョン  • フレームワーク  • APIクライアント 
• マルチテナント構成  • セキュリティ  • タイムゾーン対応  • フロントエンド  • クラス設計  • ログ  • おわりに  3  目次 

• マルチテナント構成  • セキュリティ  • タイムゾーン対応  • フロントエンド  • クラス設計  • ログ  • おわりに  4 

はじめに  2022年1月に電子帳簿保存法が改正されることになり、それに合せて急遽新サービスの開発プロジェクトが立ち上がりました。  この発表は6ヶ月の短期間でJavaで新サービスを開発をした事例の紹介になります。    法律が絡み競合他社も一斉に同じようなサービスをリリースしてくるので納期は伸ばせない... ただ自社サービスとして長い間保守開発が続くので技術的な負債を最初から作りたくない... 
この様な葛藤の中でどのように開発を進めたのかお話したいと思います。  5 

今回開発したサービス「楽楽電子保存」について  6 

開発体制  既存サービスを開発している2チームが開発  8  アルファ・チーム 6名ブラボー・チーム 7名 Tech Lead(me)  PM 
PL/PdM  基盤部分を実装するの 1人じゃ無理！！ ※実際のチーム名とは異なります 

基盤チーム 5名開発体制  一時的に基盤チームを立ち上げ  9  アルファ・チーム 4名ブラボー・チーム 5名 Tech
Lead(me)  PM  PL/PdM  開発チームからメンバーを借りて   WG的なチームで基盤部分を一気に作り上げた   大凡タスクが完了したら開発チームに人を戻した  

開発体制  「チームトポロジー」という本にこのようなチーム分けの話がありました。  （最近出た本なので読んだのは開発後ですが）  10  ❖ ストリームアラインドチーム  ➢ 顧客に直接価値を届けるいわゆる開発チーム ❖ プラットフォームチーム 
➢ インフラやツール、共通サービスなどを提供するチーム ❖ イネイブリングチーム  ➢ 他のチームが技術やスキルを身につけるのを支援するチーム ❖ コンプリケイテッド・サブシステムチーム  ➢ 複雑なサブシステムやコンポーネントを扱う専門チーム • 図らずも今回の基盤チームはプラットフォームチームとイネイブリングチーム的な役割を担っていた  • 現在、組織が拡大してチーム数が増えていっている状況の中、どうやって新しい技術を広めていくか悩んでいるところだったので非常に参考になりました  チームトポロジー  価値あるソフトウェアをすばやく届ける適応型組織設計  マシュー・スケルトン著マニュエル・パイス著 

Javaのバージョン  • 既存サービスではJava11を使っている  • 取り込めるどうか微妙なタイミングにJava17 LTSがリリースされた  　→Java11 or 17 さてどうする？ 
  12 

Javaのバージョン  • サポート期間の観点ではどうか？  ◦ Java11でもJava17でも十分長いサポート期間を提供してくれているベンダーがいるので決定的な判断ポイントにはならなかった   例）Amazon Correto  13 
https://aws.amazon.com/jp/corretto/faqs/#support より引用

Javaのバージョン  • ツール類やMWは対応しているか？  ◦ リリースサイクルが半年になった恩恵か？全然問題なかった ◦ IDEは商用のIntelliJ IDEAだったからかも（他は分からない） ◦ JacksonがRecordに対応していないのでは？と思ったが全然そんなことな
かった 14 

Javaのバージョン  • 言語仕様の差分は激しくないか？  ◦ 戸惑うような大きな言語仕様の差分はなかった ◦ Java8から一気にジャンプアップだと教育が大変だったかも ◦ 使いたい機能追加は結構あった 15 

Javaのバージョン  結論：Java17を採用した☺    16  • いつか17に上げるので移行コストが掛からない方が良い  • 新しい言語機能が使えるのはDevEx的にGood  • 学習コストはJava11と17の差分を説明したぐらいで軽微 

Javaのバージョン  時間がなくて出来なかったこと😓    17  • 使ったことがないGCの検証  ◦ 採用したかはともかく調査ぐらいはしたかった ◦ システム特性的に問題なさそうなことだけ確認してG1GCを選択
• GraalVMを検証したかった  ◦ フルネイティブ化出来なくても速くなるという話を聞いたので

Javaのバージョン  ⚠ 顧客向けクラウドサービスでは  Oracle No-Fee Terms and Conditions (NFTC)  の対象外なのでご注意ください 
  ライセンス事項を確認することをお勧めします  18 

Javaのバージョン  17の良かった新機能☺ ※Java11との比較です  • Record  19  /** * recordで書いた場合 */
public record LoginId(long value) { public LoginId { if (value <= 0L) { throw new IllegalArgumentException(); } } } Immutableなクラスが短く書けて便利なのでValue Objectの実装で多用した。    /** * classで書いた場合（今までの書き方） */ public class LoginId { private final long value; public LoginId(long value) { if (value <= 0L) { throw new IllegalArgumentException(); } this.value = value; } public long getValue() { return this.value; } }

Javaのバージョン  もしかしてrecordがあればlombokは不要では？🤔  というチームメンバーから疑問の声が  →そんなことはなかった  　確かに@Valueは使わないかもしれないが他のメソッドは使いたい  20  アノテーション用途 @Slf4j Logger
log = org.slf4j.LoggerFactory.getLogger(...);のショートハンド。めちゃくちゃ使う @AllArgsConstructorなどコンストラクター系コンストラクタでDIをインジェクションしたいのでめちゃくちゃ使う @NonNull 引数の必須チェックなどに使用する

Javaのバージョン  Java17の良かった新機能  21  • テキストブロック  ◦ 個人的には長年待ち望んでいた機能 ◦ SQLを文字列に書いたりする機会が減って思ったよりは使用ケースは少なかった ◦
テストコードではかなり使用した mockMvc.perform(MockMvcRequestBuilders.put("/user") .content("""{ "id": 1, "name": "Taro Yamada", "age": 23 }""").contentType(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) .andExpect(content().json(expected, true))

Javaのバージョン  Java17の良かった機能  • instanceofのパターンマッチング  22  そんなに多用するものではないが地味に便利  private ContentCachingResponseWrapper wrapResponse(HttpServletResponse response)
{ if (response instanceof ContentCachingResponseWrapper wrapper) { return wrapper; } else { return new ContentCachingResponseWrapper(response); } }

Javaのバージョン  Java17の地味だけど良かった機能  • stream.toList  23  List<String> list = List.of("", "a");
List<String> list2 = list.stream().filter(a -> !a.isEmpty()).toList(); collect(Collectors.toList())は長いし直感的じゃないのですごく便利  • NullPointerExceptionのエラーメッセージ改善  String s = getS(); getNull(s.toUpperCase()).getBytes(); Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.toUpperCase()" because "s" is null at BasicCompletionDemo.main(Learning.java:7) 数珠つなぎに書いてたりすると、どこがnullなのか分からないことがあったが解消されている 

フレームワーク  結論：Spring Bootを選択した  ◦ 現状、特殊な事情がない限りSpring Bootで良さそう ◦ 既存サービスではSpring MVCなのでbootJarがとても楽に感じた ▪
Tomcatの面倒をインフラにお願いしないで済むのもとても良い ◦ ヘルスチェックを実装しなくて良いのでActuatorが便利だった。   25 

フレームワーク  • Javaの性能監視にはJolokiaを使用  ◦ jmxのエンドポイントの設定が不要 ◦ APIでJSONを取得するスタイルなので汎用性が高い • Spring Actuatorが対応しているので、機能を有効にしてjolokia-coreを依存関
係に追加するだけで使用可能で便利だった。        • デフォルトでは組み込みTomcatのMbeanが取得できないので下記設定を追加しました  26  # Jolokiaでメトリクス取得するため、TomcatのMbeanを取得可能にする server.tomcat.mbeanregistry.enabled: true # healthとjolokiaを有効に management.endpoints.web.exposure.include: "health,jolokia"

APIクライアント  • SpringのRestTemplateを使おうと思ったが、調べてみると今後はメンテナンスモードになるということだったので比較検討しました  ◦ 真っ先に上がる候補はSpringのWebClientですが、このためだけにWebFluxを入れたくないので不採用とした ◦ 結局、OKHttp(Retrofit)を採用した  
• OkHttp, Retrofitとは  ◦ OkHttpはHTTP通信に特化した軽量なライブラリでAndroidでよく使われているみたいです。 ◦ RetrofitはOkHttpをラップしてより便利に使えるようにしたライブラリです。 ◦ 去年のアドベントカレンダーで3本記事を書きました 28  Retrofit+OkHttpでAPIエラーの時のレスポンスの取得ではまった Retrofit+OkHttpでmultipart/form-dataなAPIの呼び出してハマった Retrofit+OkHttpでファイルダウンロードするAPIを呼び出す

APIクライアント  29  interface UsersApiService { @GET("{tenantId}/users" ) Call<ResponseData> userList(@Path("tenantId") int
tenantId, @Query("sort") String sort); } // Responseを詰めるクラスも作っておきます record ResponseData(String status, Integer code, List<User> userList){}; record User(String name, String mailAddress){}; interfaceにAPIごとにメソッドを宣言します。   上記の例はGETで {tenantId}/users?sort={sort} を呼び出してレスポンスボディをResponseData型に詰めるという定義です   Retrofit retorofit = new Retrofit.Builder() .baseUrl("http://localhost:8080" ) // JSONを変換するコンバーターを指定（今回は Jacksonを使用） .addConverterFactory(JacksonConverterFactory.create()) .build(); // 先ほど作成したinterfaceからインスタンスを生成 UsersApiService service = retorofit.create(UsersApiService. class); // API実行！ ResponseData data = service.userList(1, "asc").execute().body(); あとは、下記のように呼び出します。UserApiServiceのメソッド呼び出しは普通のJavaのクラスを呼ぶような感覚で呼び出すことができます。 • Hello World 

マルチテナント構成  マルチテナント構成でサービスを提供しています  ▪マルチテナント構成とは？  サーバーを複数テナントで共用する構成  • コストメリット  • スケーラビリティ    31 
https://jesusgilhernandez.com/2012/12/13/multitenancy-architecture/

　低　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　マルチテナント構成  高  32  　高　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 A. データベース分離方式 B. 単一データベース・個別スキーマ方式 C.
単一データベース・共通スキーマ方式初期構築コスト  運用コスト  —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- —----- -------- マルチテナント構成の実現方法  低 

マルチテナント構成  単一データベース・共通スキーマ方式を採用  • これまでは単一データベース・個別スキーマ方式を採用していたがお客さんが増えるに従ってスキーマ数が増えることで管理が大変という問題がある  • 今回はユーザ特性的にもこの方式が向いていたので無理なく採用  33  テナントID 請求書ID
金額 1 100 1,000,000 2 101 2,000,000 基本すべてのテーブルにテナントIDを持ちます  

マルチテナント構成  34  CREATE POLICY isolation_policy ON [table_name] USING (tenant_id =
current_setting('app.current_tenant_id')::bigint); • PostgreSQLのRow Level Security(RLS)で他テナントのレコードを間違って検索しないことを担保  ◦ 万が一SQLでtenant_idでの絞り込みを間違っても、app.current_tenant_idに指定した以外のデータは取得できないことが担保できる

マルチテナント構成  35  • app.current_tenant_idの設定はトランザクションごとに設定するようにspringの DataSourceTransactionManagerを拡張  public class MyTransactionManager extends DataSourceTransactionManager
{ @Override protected void prepareTransactionalConnection (Connection con, TransactionDefinition definition) throws SQLException { super.prepareTransactionalConnection(con, definition); try (Statement stmt = con.createStatement()) { stmt.execute("SET local app.current_tenant_id = " + TenantContextHolder .getTenantId()); } } } • ここまで仕組みを作ったのでこれで安心できた  • RLSはSaaSの業界で最近流行っているようで沢山事例が公開されていて参考になりました 

セキュリティ  • 認証やCSRFチェックはSpring Securityを使用  ◦ デフォルトで必須級のセキュリティ系のヘッダーを付与してくれるので楽だった 37  Cache-Control: no-store, no-cache,
must-revalidate, max-age=0 Pragma: no-cache Expires: 0 X-XSS-Protection: 1; mode=block X-Frame-Options: DENY X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000; includeSubDomains

セキュリティ  38  不足するヘッダーだけ自分で設定した Content-Security-Policyはユーザが沢山いる状態で入れるのは大変なので早めに入れられて良かった Referrer-Policy "strict-origin-when-cross-origin" Content-Security-Policy "default-src 'self'; connect-src
'self' https://www.google-analytics.com; img-src 'self' https://www.google-analytics.com; script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/; font-src https://fonts.googleapis.com/ https://fonts.gstatic.com/; child-src 'none'; object-src 'none'" 「体系的に学ぶ安全なWebアプリケーションの作り方第2版脆弱性が生まれる原理と対策の実践」（徳丸本）は必読ですが、ちょっと前に出た「Webブラウザセキュリティ」という本もとても参考になりました。 Webブラウザセキュリティ ― Webアプリケーションの安全性を支える仕組みを整理する　米内貴志著 

セキュリティ  • 認証処理を組み込んだところ性能問題が発生  ◦ 計測したらログインに2秒近く掛かっていた。 ◦ プロファイルを取ってみるとBCryptPasswordEncoderが遅いことが分かった ◦ 社内のセキュリティ要件に従うためstrengthに14(16384回ストレッチ)を指定したのが原因 ▪
この件をQiitaにまとめて下さっている人がいました • JavaでBCrypt + ストレッチ回数ごとの処理時間計測 • デフォルトの1024回ストレッチでも100ms以上掛かっているのでそもそもコストが高い処理 ◦ BCryptPasswordEncoderを使用せずに自前実装に切り替えたところ1500msから350msまで改善しました ▪ なんでこんなに違いが出るのかは細かいことは分かっていません。 39 

タイムゾーン対応  • ファーストリリースでは日本国内での使用のみ想定すれば良いのだが、将来的に海外対応が必要になる確度が高いので最初からTimezoneありきで実装を行った。  ◦ LocalDatetimeで実装して後から海外対応しようとすると修正箇所が多すぎて辛い ◦ ただし、夏時間を考慮しようとすると途端に難しくなるのでここでは考慮しない 41 
APサーバユーザの入力値：2022-05-10 10:00:00 2022-05-10 T01:00:00+00 ZonedDateTime: 2022-05-10 10:00:00(Asia/Tokyo) OffsetDateTime: 2022-05-10 01:00:00+00 DB  とりあえずAsia/Tokyo固定   でZonedDateTimeで受け取る   OffsetDateTime(UTC)に変換して処理する  DBにはUTCで格納   ※データの取得は逆の順番で同じように行う  

タイムゾーン対応  42  • PostgreSQLの timestamp with time zone型について  timestamp with
time zoneについて内部に格納されている値は常に UTCです（協定世界時、歴史的にグリニッジ標準時 GMTとして知られています）。時間帯が明示的に指定された入力値は、その時間帯に適したオフセットを使用して UTCに変換されます。入力文字列に時間帯が指定されていない場合は、システムの TimeZoneパラメータに示されている値が時間帯とみなされ、timezone時間帯用のオフセットを使用して UTCに変換されます。（公式ドキュメントより引用）初めて使いましたが、下記の点がちょっと意外でした  • 時間帯を明示しないと実行環境のTimezoneへの変換が自動で行われる  • 名前に反してtimezone情報は保持しない。常にUTCに変換して保存される  ◦ 確かにtimezoneあり/なし、どちらも格納サイズは8バイトで違いはない

タイムゾーン対応  43  app=# set timezone to 'Asia/Tokyo'; タイムゾーンをAsia/Tokyoにセットする（大抵の場合デフォルトこれ） SET app=#
insert into test values(2, '2022-05-09 16:47:29');　日本時間(+0900)の2022-05-09 16:47:29としてインサート INSERT 0 1 app=# select * from test; id | start_time ----+------------------------ 2 | 2022-05-09 16:47:29+09　日本時間(+0900)で取得される。 (1 row) • SQLクラインアントから実行すると、自動的に日本時間に変換してくれるのでデバッグや運用でのDB操作は問題なさそう 

タイムゾーン対応  ◦ JavaからDBアクセス時に実行環境のtimezoneの影響を受けないようにJVMパラメータで UTC固定にした 44  -Duser.timezone=UTC ◦ 開発当初はuser.timezoneを指定せず、更にDB Unitのテストデータにもオフセットを指定していなかったため日本時間としてロードされてしまい日本時間なのかUTCなのか訳が分から
ない状態になり現場を混乱させてしまった ◦ オフショア開発する可能性もあったのでテストデータにはオフセットを明記するルールにしておいた方が良かったと後から思いました

フロントエンド  • 既存サービスを踏襲して、今回のサービスでもReactを採用  ◦ サーバー側はJSONを返却するAPIを実装する ◦ I/Fだけ固めてしまってフロント側は基本的にお任せ ◦ サーバ側だけでも覚えることが多くなってきており責任分界点ができて良い  
• フロントエンドについてはJJUG CCC 2021 Springで同僚が話をしていますので良ければご覧ください  ◦ 「フロントエンド・バックエンド分離の道のり」 ◦ https://fortee.jp/jjug-ccc-2021-spring/proposal/a0cc4346-f001-44dc-8df4-5974ce40b767 ◦ https://www.youtube.com/watch?v=1b3riDczwkQ   46 

クラス設計  Springのstereotypeを使って素直に実装すると3層アーキテクチャになる    48  @Controller @Service @Repository ビュー: JSPなどプレゼンテーション層（UI層）： 
　表示、入力内容受け取り、入力内容のチェック、  　UIに合わせた形式変換  ビジネスロジック層（ドメイン層）：  　業務処理を実装する  データアクセス層（インフラ層）：  　データベースとやりとりを実装する 

クラス設計  • ３層アーキテクチャのメリット  ◦ いわゆる「トランザクションスクリプト」に処理をつらつら書いて行けばやりたいことが実現できる（オブジェクト指向を分かってなくていい） ◦ クラス設計にコストが掛からないので高速に開発できる ◦ ユースケース単位で分担して実装すれば良いので平行して作業しやすい
  • ３層アーキテクチャのデメリット  ◦ 処理の共通化はその人任せになり同じ処理が重複して書かれがちになる ◦ 修正の影響がどこに出るのか探しにくい ◦ 影響があちこちにでてしまう   デメリットは既存サービスで味わってきた。  長期メンテナンスには辛い構造なので時間がなくても今回のサービスでは採用しない  49 

クラス設計  デメリットはビジネスロジック層に集中しているのでテコ入れする  50  @Controller @Service @Repository ビュー: JSPなどプレゼンテーション層（UI層）：  　表示、入力内容受け取り、入力内容のチェック、 
　UIに合わせた形式変換  ビジネスロジック層（ドメイン層）：  　業務処理を実装する  データアクセス層（インフラ層）：  　データベースとやりとりを実装する  この層を細分化するルールを作成すれば良さそう🤔

クラス設計  オニオンアーキテクチャを採用した  51  アプリケーション層ドメイン層インフラストラクチャ層ユーザインターフェース層アプリケーション層ドメイン層インフラストラクチャ層
ユーザインターフェース層レイヤードアーキテクチャ  オニオンアーキテクチャ  ３層アーキテクチャのビジネスロジック層が分離された  ドメイン層  アプリケーション層   ユーザインターフェース層   インフラストラクチャ層   丸で表現するとタマネギみたいな形になるのが由来  この依存度の向きが逆  他にもヘキサゴナルアーキテクチャやクリーンアーキテクチャがあるがそこまで複雑なものは必要なくオニオンアーキテクチャがちょうど良かった 

クラス設計  • ユースケースをアプリケーション層に、業務ロジックをドメイン層に書くように分離できた  ◦ ドメイン層をエンティティやバリューオブジェクトなど、共通認識を持って実装できるのが大きい ◦ とりあえず小さく始めるならバリューオブジェクトに切り出すことをお勧め 52 

クラス設計  53  • とは言え、クラスを設計すること自体に慣れてなく苦戦は必至だった  ◦ だいぶ前から読書会や勉強会を主催、良記事の紹介など地道な啓蒙活動を行った ◦ 既存サービスで部分的に実践 ◦ 理解を深めるため何冊も本を読みました
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)　エリック・エヴァンス著  ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本　成瀬允宣著  ドメイン駆動設計モデリング/実装ガイド　松岡幸一郎著  ドメイン駆動設計サンプルコード&FAQ　松岡幸一郎著  セキュア・バイ・デザイン　Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano 著 

ログ  • 運用時の調査のためリクエスト/レスポンス情報をログ出力したい  • ユーザの入力値など機微情報は除外してデータを特定するID項目だけをログに出力したい  • Springのフィルターは全てログに出力してしまうため使えない  •
機微情報を意識しながらControllerでログ出力実装をしたくない  →ログ出力をするFilterを実装すれば簡単にできそう🤔  55 

ログ  • Responseからデータを取得しログ出力できたが後続の処理でストリームが閉じられていると言ってエラーになってしまう  56  やってみたら意外と難しかった。 

ログ  • AbstractRequestLoggingFilterを参考にContentCachingRequestWrapper、 ContentCachingResponseWrapperを使用するように実装しました  57  @AllArgsConstructor public class RequestAndResponseLoggingFilter extends
OncePerRequestFilter { @Override protected void doFilterInternal (@NonNull HttpServletRequest request, @NonNull HttpServletResponse response, @NonNull FilterChain filterChain) { doFilterWrapped(wrapRequest(request), wrapResponse(response), filterChain); } private void doFilterWrapped (ContentCachingResponseWrapper request, ContentCachingResponseWrapper response) { try { // リクエストログ出力（予め指定してキーに絞ってログ出力） writeRequestLog(request); // 処理の実行 long start = System.currentTimeMillis(); filterChain.doFilter(request, response); long latency = System.currentTimeMillis() - start; // レスポンスログ出力（予め指定してキーに絞ってログ出力） writeResponseLog(response , latency); } finally { response.copyBodyToResponse(); // レスポンスに書き込み } } private ContentCachingResponseWrapper wrapRequest(HttpServletRequest request) { return new ContentCachingResponseWrapper (request); } private ContentCachingResponseWrapper wrapResponse(HttpServletResponse response) { if (response instanceof ContentCachingResponseWrapper wrapper) { return wrapper; } else { return new ContentCachingResponseWrapper(response); } } }　 ※メモリ使用量は増えると思いますので、ご注意を。 

他にも沢山のタスクをこなす必要がある...  • パブリッククラウド or オンプレ検討  • コンテナ or VM or
物理サーバ  • システム構成検討  • スケールアウト方式検討(APP/DB)  • バックアップ・リストア検討  • ドメイン取得  • URL設計  • SSL証明書取得(暗号化方式, TLSバージョン）  • ログ設計(syslogの設計)  • CI設定  • systemd設定  • サーバのディレクトリ構成設計  • オブジェクトストレージ設計  • 各種タイムアウト値設計  • リクエストサイズの上限設定 (servlet.multipart.maxFileSize, servlet.multipart.maxRequestSize)  • Cookie設計  • セッション設計  • LBの設定(Sticky Session)  • PostgreSQLの設定値検討  • PostgreSQLのスキーマ設計  • PostgreSQLのRole設計  • コネクションプーリング検討  58  • JVMパラメータ設計（ヒープサイズ、Metaspaceなど）  • GC設計(GC種類の検討、GCログなど)  • 性能測定  • パッケージ設計  • 使用するMWのライセンス確認  • 排他制御の方式検討  • ウィルススキャン検討  • コーディング・DB規約作成  • バッチ設計  • 制御文字チェック（nullやnbspなどバイト列）  • メール設計(spf、dkim、smtp、メールヘッダーの検討など)  • メールテンプレート設計(テンプレートエンジンは何を使うかなど)  • TomcatやSpringのエラー画面を表示させない対応  • ステージング設計  • ヘルスチェック設計  • APM検討  • 文字コード検討  • クローラー対策  • 脆弱性チェック  • 運用設計（スレッドダンプの取得方法の検討など）  • メッセージ設計(他言語対応しやすいようにベタ書き禁止)  • ORマッパーの検討  • Reactのためのmod_rewrite設定 

🎊予定通り無事ローンチできた🎉      （電子帳簿保存法に二年間の猶予期間が設けられたのはまた別の話😂）   59 

おわりに  • すべてが理想通りとは行かなかったが納期を守ってリリースできた  • 久しぶりに新サービスを開発をしてみて、1つのサービスを作るために必要なことは沢山あることを改めて実感した  • 新しい技術要素を試すためには日頃からの仕込みが重要  • 半年サイクルのリリースになりJavaはリリース直後でも安心して利用でき
た  60 

🏁ご清聴ありがとうございました🏁  61 

短納期でローンチした新サービスをJavaで開発した話/launched new service...

短納期でローンチした新サービスをJavaで開発した話/launched new service using Java

More Decks by A1

Other Decks in Programming

Featured

Transcript