Apache Camel Advent Calendar 17日目の記事は、サポート担当古市が担当します。 テーマは、「Camel アンチパターン」
技術書籍では良く目にする「アンチパターン」というトピックですが、サポート窓口での対応を通して感じることはあります。 今回はサポート体験を通して気がついた Camel の取り扱い注意点についてご紹介します。
恐らく開発と保守が別れており、保守の方からのお問い合わせだからと思われますが、圧倒的に多い調査初動のトラブルがこちら。
- 問題となっているログがどの Camel route から出力されているか分からない。
12日目の記事でお話した問題です。 route template を積極的にご利用いただくことで、保守への負荷を下げるようご検討ください。
次に、3日目の記事で軽く触れましたが、こちらも大きな課題だと感じます。
- Camel Component をほぼ使用せず、常に カスタムプロセッサーや Java Bean の実行でルーティングを構成する。
Camel Component を上手に取り込んだ camel route は、汎用性や拡張性が高く、保守の負荷も下がります。障害調査の際、芸術的に設計された camel route を拝見して感動したことがあります。 逆を言えば、ルーティングに property や variable を活用せず、ハードコードに近い Java Beanのみを乱用する camel route を拝見すると、正直 Quarkus単体で実装を済ませても良いぐらいに思えてしまいます。
何かがおかしいと思われた場合、積極的に camel community をご活用ください。きっとコミュニティーからリファクタリングのアドバイスをもらえるはずです。(過去に、数百の camel routeを 3つにまとめられるというアドバイスもありました。)
3つ目の課題はこちら。
- 複雑な処理を組み込み過ぎて、パフォーマンスが上がらない。
パフォーマンスに関するお問い合わせも多々ございます。中でも目立つ split / aggreate の使い方で特に気をつけていただきたいのが、とにかく軽めの処理で終わらせることです。 aggregate 処理中に別途 JDBCを使った SQL 処理をされている方もいらっしゃいました。メッセージのルーティングに関わる split / aggregate などの処理は極力シンプルで軽い処理で済ますべきです。 (補足となりますが split の際、message body が GB単位のテキストファイルというケースがたまにありますが、ストリーミング形式で読み取らないとヒープ領域が枯渇してしまうというトラブルに繋がりますので、ご注意ください。) camel component を使うべきとお伝えした後に矛盾するコメントとなりますが、不用意に複雑な機能を使う必要はありません。スモールスタートで少しづつ拡張するようご検討ください。
せっかく Camel の導入を検討されているのですから、このツールボックスの真の素晴らしさを体験していただきたいと心から願っています。 何か上手くいかないと感じましたら、お気軽にサポートサービスもご利用ください。アップストリームで活躍している開発スタッフ達を含め、皆様のお役に立てるよう対応させていただきます。
明日の advent calendar 18日目では、「Camel ベストプラックティス」についてご紹介します。 アドベントカレンダーの一覧はこちらです。 qiita.com
