I have an application A which is strictly working together with application B. They're kind of pieces of a bundle.
Currently they are interacting between each other via HTTP calls. When app A needs something, it sends an HTTP API call to app B. But since HTTP is much more slower than Redis calls, I consider to change my flow as using Redis set/gets instead of HTTP calls.
No any other applications needs to have same relationship as A and B do.
So, is using Redis to share data between two applications instead of API calls against separation of concerns principle or not?
The Separation of Concerns is about your code not being tightly coupled to some other classes/systems. If you are hardwiring your application into Redis, you already are violating the SoC principle.
Currently you seem to have a consumer-producer architecture. Doing what you are planning to do means that your are switching to a repository-based arcitecture.
The main question is how are you going to organize your components.
It seems like you can follow one of the approches bellow:
Redis runs on the same server as application A (or B) and application B (or A) accesses it through the network when it needs.
Redis runs on both aplication A and B server, working as a cluster.
Redis runs on a separate server, which application A and B servers will access it through the network when necessary.
Furthermore, you might have to create a layer on top of your redis implementation to decouple your application from an specific storage implementation.
Having only one point of data access instead of two leads you towards the SoC principle, not the other way around.